On Mon, Jun 8, 2020 at 5:35 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Thu, Jun 4, 2020 at 10:49 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > On Tue, Jun 2, 2020 at 8:52 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > On Tue, Jun 2, 2020 at 8:47 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > > > > > We deprecated the SELinux runtime disable functionality in Linux > > > > v5.6, add a five second sleep to anyone using it to help draw their > > > > attention to the deprecation. > > > > > > > > Signed-off-by: Paul Moore <paul@xxxxxxxxxxxxxx> > > > > --- > > > > security/selinux/selinuxfs.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > Warning: while trivial, I've done no testing beyond a quick compile > > > yet. I'm posting this now to see what everyone thinks about starting > > > to make it a bit more painful to use the runtime disable > > > functionality. > > > > I'm concerned about how users will experience and respond to this > > change (and Linus too). Currently SELinux runtime disable is the > > method used by distro installers (at least Fedora/RHEL and > > derivatives) when SELinux-disabled is selected at install time and it > > is the approach documented in distro documentation for how to disable > > SELinux. Hence, we'd be inflicting pain on the end users for what is > > essentially a distro choice. > > I delayed my response in hopes the Fedora folks would also comment, > but I'm not seeing anything. > > All this patch does is start executing on the deprecation path we laid > out when we marked the functionality as deprecated. When we decided > to do this we had buy-in from the Fedora folks (the only ones who > still use this option); if this is a problem for them then I would > like to understand what changed, and why. If it is a matter of this > coming too quickly, that's okay, we can push this out another release > or two. We can even drop the sleep down to a second or two. Both the > timing of introducing the delay, and the length of the delay itself, > aren't important to me; it's the fact that we are adding a delay and > moving forward on the deprecation (just as we said we would). > > What were you envisioning when we marked this as deprecated Stephen? > If not this, what were you thinking we would do? I feel like we've already communicated the fact that it is being deprecated to those who need to know (Fedora maintainers), and we already have it displaying an error message for those who look at kernel logs. So I was fine with just waiting some number of kernel release cycles (not sure what is typical for these kinds of things) and then just changing selinux_write_disable() to just return 0 without doing anything and dropping the selinux_disable() code and the config option. I think we'll want it to return 0 rather than an error so that systemd will still unmount selinuxfs and act as if SELinux has been disabled (which in turn will case everything else to act as if SELinux has been disabled). The kernel will be in permissive mode with no policy loaded in that situation, so except for some corner cases everything should just work. That seems the least disruptive path for end users. Distro maintainers will hopefully get around to using selinux=0 instead but that may lag.
