Allow spc_t execstack and execmem (bsc#1268490)#472
Conversation
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates SELinux policy so the spc_t domain, now part of unconfined_domain instead of container_domain, is explicitly granted execmem and execstack permissions again to restore needed behavior for containers (e.g., Java apps) on openSUSE. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
This commit moved spc_t out of the container_domain: "Tighten controls on confined users" containers@2361047 The container_domain lists execmem and execstack explicitly: https://github.com/containers/container-selinux/blob/f786136f58c4e1b7568f30463a44b050d0d84325/container.te#L1127 Now it is in unconfined_domain: https://github.com/containers/container-selinux/blob/f786136f58c4e1b7568f30463a44b050d0d84325/container.te#L852C2-L852C27 execmem and execstack are allowed for unconfined_domain in fedora, but not openSUSE. Since containers (especially java application containers) need those pretty often, lets allow that explicitly for spc_t again. Signed-off-by: Cathy Hu <cathy.hu@suse.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the SELinux policy in container.te to allow spc_t processes both execstack and execmem permissions. Feedback on this change highlights a security concern: enabling execstack significantly increases vulnerability to memory corruption exploits and is rarely necessary for modern applications. It is recommended to restrict the permission to execmem only, unless execstack is explicitly required.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| # spc local policy | ||
| # | ||
| allow spc_t { container_file_t container_var_lib_t container_ro_file_t container_runtime_tmpfs_t}:file entrypoint; | ||
| allow spc_t self:process { execstack execmem }; |
There was a problem hiding this comment.
Allowing execstack (executable stack) poses a significant security risk as it makes memory corruption vulnerabilities (like buffer overflows) much easier to exploit. While execmem is commonly required by runtimes like Java for Just-In-Time (JIT) compilation, execstack is rarely needed by modern applications. To adhere to the principle of least privilege, consider allowing only execmem unless there is a verified requirement for execstack in spc_t containers.
allow spc_t self:process { execmem };
There was a problem hiding this comment.
I think the AI did not read my commit message.
There was a problem hiding this comment.
Can we do this as a boolean. I would allow execmem by default and have a container_can_execstack boolean. Then users can just toggle the boolean.
|
Ephemeral COPR build failed. @containers/packit-build please check. |
|
Tests failed. @containers/packit-build please check. |
2 participants
This commit moved spc_t out of the container_domain: "Tighten controls on confined users"
2361047
The container_domain lists execmem and execstack explicitly:
container-selinux/container.te
Line 1127 in f786136
Now it is in unconfined_domain:
https://github.com/containers/container-selinux/blob/f786136f58c4e1b7568f30463a44b050d0d84325/container.te#L852C2-L852C27
execmem and execstack are allowed for unconfined_domain in fedora, but not openSUSE.
Since containers (especially java application containers) need those pretty often, lets allow that explicitly for spc_t again.
Summary by Sourcery
Enhancements: