linux-kernel - Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.21.1810030758460.23596@namei.org>
Date:   Wed, 3 Oct 2018 08:06:12 +1000 (AEST)
From:   James Morris <jmorris@...ei.org>
To:     Kees Cook <keescook@...omium.org>
cc:     John Johansen <john.johansen@...onical.com>,
        Jordan Glover <Golden_Miller83@...tonmail.ch>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Paul Moore <paul@...l-moore.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        "Schaufler, Casey" <casey.schaufler@...el.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter

On Tue, 2 Oct 2018, Kees Cook wrote:

> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> <john.johansen@...onical.com> wrote:
> > Under the current scheme
> >
> > lsm.enabled=selinux
> >
> > could actually mean selinux,yama,loadpin,something_else are
> > enabled. If we extend this behavior to when full stacking lands
> >
> > lsm.enabled=selinux,yama
> >
> > might mean selinux,yama,apparmor,loadpin,something_else
> >
> > and what that list is will vary from kernel to kernel, which I think
> > is harder for the user than the lsm.enabled list being what is
> > actually enabled at boot
> 
> Ah, I think I missed this in your earlier emails. What you don't like
> here is that "lsm.enable=" is additive. You want it to be explicit.
> 

This is a path to madness.

How about enable flags set ONLY per LSM:

lsm.selinux.enable=x
lsm.apparmor.enable=x

With no lsm.enable, and removing selinux=x and apparmor=x.

Yes this will break existing docs, but they can be updated for newer 
kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from 
kernel X onwards.

Surely distro packages and bootloaders are able to cope with changes to 
kernel parameters?

We can either take a one-time hit now, or build new usability debt, which 
will confuse people forever.


-- 
James Morris
<jmorris@...ei.org>