-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify position around SELinux support #439
Comments
Note that the docs always recommend trying running in permissive mode to debug in order to nudge folks to go back to enforcing. Folks that do not want to run SELinux at all don't need to do that and can just fully disable it. |
I'm not sure in that sentence if you were talking about FCOS also or just traditional systems, but just to be clear, today rpm-ostree does not support SELinux disabled. So |
From meeting discussion, I think there is consensus on this.
I do not disagree that this is indeed possible, but at the same time my feeling is that this mainly a hypothetical/corner-case scenario. If anything, this seems to hint that (in theory) there may be files written to disk with the wrong label, which may cause troubles if the system is temporarily running in permissive mode and later reverses to enforcing. |
Thanks, I did not know about that.
I've seen this happen some times but unfortunately I don't have an example at hand. In enforcing mode the kernel will not block actions not allowed in the policy but it will still not accept doing some operations. For example, it will not accept running a process under a domain that has no meaning for the SELinux policy. Some applications (pam, etc.) also behave differently when SELinux is enabled (permissive or enforcing). See this particular paragraph: https://wiki.gentoo.org/wiki/SELinux/Tutorials/Permissive_versus_enforcing#Differences_in_application_behavior In the end, given that we can not "recommend" not running SELinux at all then I think my point doesn't matter. Should we still add something to the docs? |
I'm not so sure. At least I'm not convinced. Yes, we only test it enforcing and probably aren't going to go to a lot of trouble to fix issues specifically related to permissive mode, but I do see it as reasonable to tell people to try permissive mode if they are having a lot of trouble with their application (i.e. something specific to their deployment and not something that affects a broad class of users). I guess what I'm trying to say is that I would rather someone use FCOS in permissive mode than to tell them to go somewhere else if they don't want selinux enforcing. As far as disabled versus permissive. I've always been under the opinion that putting selinux into disabled mode and running your system in that way is hard to recover from (i.e. go back to At the end of the day if I ever need to troubleshoot I always go to permissive mode and not disabled. I think all permissive does is just log things rather than actually deny things. I don't think there are fundamental reasons why permissive mode is bad or unsupportable. |
Right we definitely don't support on rpm-ostree systems going from |
I think we can reasonably ask folks to re-provision the system when moving from disabled to enabled again. Is coreos/rpm-ostree#971 about |
Can we revisit the "Clarify somewhere in the docs that only SELinux enabled and enforcing is supported" point? I'm thinking that's too strong and we shouldn't say permissive isn't allowed. |
I don't think we should say it's not allowed (users do whatever they want). We just have to be honest and say that we only test enabled and nothing else is officially supported (i.e. you're on your own, might work, might not). |
Clarify somewhere in the docs that only SELinux enabled and enforcing is supported (in other words, that's what we test in CI).
SELinux is part of the security layers that provide isolation between different containers and between containers and the host.
If folks do not want to use SELinux, they should disable it fully via a kernel argument:
selinux=0
.It is not recommended to run a production server with SELinux in permissive mode as this will not provide any security and can lead to complex issues as permissive mode is only for debugging and can create hard to diagnose issues as applications can get executed into the wrong domains and thus report wrong AVC:
From https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/#selinux-Enabling_and_Disabling_SELinux-Dracut-parameters
The docs at https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/#selinux-disabling-selinux is also ambiguous but goes into the same direction.
For debugging, it's usually better to turn a single domain into permissive mode using
semanage permissive -a domain_t
(that we don't ship by default).Triggered by the discussion in coreos/fedora-coreos-tracker#1222 around https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel
RHEL docs: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/changing-selinux-states-and-modes_using-selinux
The text was updated successfully, but these errors were encountered: