Clarify position around SELinux support

[travier]

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:

Moreover, in permissive mode the system continues to create the labels correctly.
The AVC messages that are created in this mode can be different than in enforcing
mode. In permissive mode, only the first denial is reported. However, in enforcing
mode you might get a denial on reading a directory and an application stops. In
permissive mode, you get the same AVC message, but the application continues
reading files in the directory and you get an AVC for each denial in addition.

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

[travier]

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.

[travier]

https://wiki.gentoo.org/wiki/SELinux/Tutorials/Permissive_versus_enforcing

[jlebon]

If folks do not want to use SELinux, they should disable it fully via a kernel argument: selinux=0.

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 selinux=0 will not work in FCOS. See coreos/rpm-ostree#971.

[lucab]

Clarify somewhere in the docs that only SELinux enabled and enforcing is supported

From meeting discussion, I think there is consensus on this.

in permissive mode [...] applications can get executed into the wrong domains

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.
But more to the point, if a system is persistently running in permissive mode, then wrong labels and execution domains are not a concern: the user explicitly disabled a security gating mechanism, and going forward the system won't really care about mismatched labels/domains.

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.
If so, then the real hazard seems to be centered around going through this "temporarily permissive mode for debugging purposes" and back to "steady-state enforcing". In that case, files could have been mislabeled/modified/removed in a unexpected or insecure way, and hysteresis effect could (in theory) be observed.

[travier]

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 selinux=0 will not work in FCOS. See coreos/rpm-ostree#971.

Thanks, I did not know about that.

in permissive mode [...] applications can get executed into the wrong domains

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. But more to the point, if a system is persistently running in permissive mode, then wrong labels and execution domains are not a concern: the user explicitly disabled a security gating mechanism, and going forward the system won't really care about mismatched labels/domains.

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?

[dustymabe]

Clarify somewhere in the docs that only SELinux enabled and enforcing is supported

From meeting discussion, I think there is consensus on this.

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 enforcing later). It also can break the assumptions of some applications (i.e. they assume selinux facilities are there and might break if it's not). These apps should arguably be made to "error" in a more graceful way, but not a lot of effort is put into that for fair reasons.

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.

[cgwalters]

Right we definitely don't support on rpm-ostree systems going from selinux=0 (to the default of selinux=1), partly because doing that correctly would require teaching the autorelabeling stuff very explicitly about the special /sysroot/ostree stuff.

[travier]

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 selinux=0 not working at all or just the transition from disabled to enabled that is broken?

[dustymabe]

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.

[travier]

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).