On Fri, Mar 17, 2023 at 7:15 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>
> On 3/17/2023 12:56 PM, Paul Moore wrote:
> > After working with the larger SELinux-based distros for several
> > years, we're finally at a place where we can disable the SELinux
> > runtime disable functionality. The existing kernel deprecation
> > notice explains the functionality and why we want to remove it:
> >
> > The selinuxfs "disable" node allows SELinux to be disabled at
> > runtime prior to a policy being loaded into the kernel. If
> > disabled via this mechanism, SELinux will remain disabled until
> > the system is rebooted.
> >
> > The preferred method of disabling SELinux is via the "selinux=0"
> > boot parameter, but the selinuxfs "disable" node was created to
> > make it easier for systems with primitive bootloaders that did not
> > allow for easy modification of the kernel command line.
> > Unfortunately, allowing for SELinux to be disabled at runtime makes
> > it difficult to secure the kernel's LSM hooks using the
> > "__ro_after_init" feature.
> >
> > It is that last sentence, mentioning the '__ro_after_init' hardening,
> > which is the real motivation for this change, and if you look at the
> > diffstat you'll see that the impact of this patch reaches across all
> > the different LSMs, helping prevent tampering at the LSM hook level.
> >
> > >From a SELinux perspective, it is important to note that if you
> > continue to disable SELinux via "/etc/selinux/config" it may appear
> > that SELinux is disabled, but it is simply in an uninitialized state.
> > If you load a policy with `load_policy -i`, you will see SELinux
> > come alive just as if you had loaded the policy during early-boot.
> >
> > It is also worth noting that the "/sys/fs/selinux/disable" file is
> > always writable now, regardless of the Kconfig settings, but writing
> > to the file has no effect on the system, other than to display an
> > error on the console if a non-zero/true value is written.
> >
> > Finally, in the several years where we have been working on
> > deprecating this functionality, there has only been one instance of
> > someone mentioning any user visible breakage. In this particular
> > case it was an individual's kernel test system, and the workaround
> > documented in the deprecation notice ("selinux=0" on the kernel
> > command line) resolved the issue without problem.
> >
> > Signed-off-by: Paul Moore <paul@xxxxxxxxxxxxxx>
>
> Except for the Documentation fumble noted below,
Yes, Daniel also pointed that out and it's fixed in my dev branch.
> enthusiastically ...
> Reviewed-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
> or, if you'd prefer ...
> Acked-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
Generally I prefer 'Reviewed-by' tags as they imply that someone
actually read/reviewed the code, but since this patch does technically
touch the Smack code I think the ACK is probably more appropriate
here. Regardless, thanks for the review/ACK.
--
paul-moore.com
