On Mon, Mar 20, 2023 at 11:14 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote:
>
> This looks great, but I cannot apply it on any of these trees: Linus's,
> the LSM's next, nor the next one.
Likely because it's based on the SELinux next branch with the
checkreqprot removal patch added on top as I expect to merge both of
these patches soon. There have also been some pretty widespread
changes in the SELinux tree this dev cycle outside these two
deprecation/removal patches.
One could make an argument that this should go in via the LSM tree as
it touches all of the LSMs, but those impacts are trivial, and the
SELinux changes are more significant so I made the decision to do the
development and merge the patch via the SELinux tree.
> On 17/03/2023 20:56, 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>
> > ---
> > .../sysfs-selinux-disable | 3 +
> > include/linux/lsm_hooks.h | 7 ---
> > security/Kconfig | 5 --
> > security/apparmor/lsm.c | 6 +-
> > security/bpf/hooks.c | 4 +-
> > security/commoncap.c | 2 +-
> > security/landlock/cred.c | 2 +-
> > security/landlock/fs.c | 2 +-
> > security/landlock/ptrace.c | 2 +-
> > security/landlock/setup.c | 4 +-
> > security/loadpin/loadpin.c | 2 +-
> > security/lockdown/lockdown.c | 2 +-
> > security/security.c | 4 +-
> > security/selinux/Kconfig | 24 --------
> > security/selinux/hooks.c | 57 +------------------
> > security/selinux/include/security.h | 21 -------
> > security/selinux/selinuxfs.c | 43 ++------------
> > security/smack/smack_lsm.c | 4 +-
> > security/tomoyo/tomoyo.c | 6 +-
> > security/yama/yama_lsm.c | 2 +-
> > 20 files changed, 32 insertions(+), 170 deletions(-)
> > rename Documentation/ABI/{obsolete => removed}/sysfs-selinux-disable (90%)
--
paul-moore.com
