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.1810050338470.14095@namei.org>
Date:   Fri, 5 Oct 2018 03:49:14 +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 Wed, 3 Oct 2018, Kees Cook wrote:

> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@...ei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >   - All LSMs which are built are NOT enabled by default
> >
> >   - You specify enablement and order via a Kconfig:
> >
> >         CONFIG_LSM="selinux,yama"
> >
> >   - This can be entirely overridden by a boot param:
> >
> >         lsm="apparmor,landlock"
> 
> This doesn't work with how SELinux and AppArmor do their bootparams,
> unfortunately. (And Paul and Stephen have expressed that the
> documented selinux on/off must continue to work.) For example, let's
> say you've built an Ubuntu kernel with:
> 
> CONFIG_SELINUX=y
> ...
> CONFIG_LSM="yama,apparmor"
> 
> (i.e. you want SELinux available, but not enabled, so it's left out of
> CONFIG_LSM)
> 
> Then someone boots the system with:
> 
> selinux=1 security=selinux
> 
> In what order does selinux get initialized relative to yama?
> (apparmor, flagged as a "legacy major", would have been disabled by
> the "security=" not matching it.)

It doesn't, it needs to be specified in one place.

Distros will need to update boot parameter handling for this kernel 
onwards.  Otherwise, we will need to carry this confusing mess forward 
forever.

> The LSM order needs to be defined externally to enablement because 
> something may become enabled when not listed in the order.
> 
> Now, maybe I misunderstood your earlier suggestion, and what you meant
> was to do something like:
> 
> CONFIG_LSM="yama,apparmor,!selinux"
> 
> to mean "put selinux here in the order, but don't enable it". Then the
> problem becomes what happens to an LSM that has been built in but not
> listed in CONFIG_LSM?

In my most recent suggestion, there is no '!' disablement, just 
enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.

> Related to that, this means that when new LSMs are added, they will
> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
> that's really how we have to go, I'll accept it, but I think it's a
> bit unfriendly. :P

If you want to enable them, yes.  How is this different to adding new 
mount options as new fs features become available?


> Another reason I don't like it is because it requires users to know
> about all the LSMs to make changes. One LSM can't be added/removed
> without specifying ALL of the LSMs. (i.e. there is no trivial way to
> enable/disable a single LSM without it growing its own enable/disable
> code as in SELinux/AppArmor. I'd hoped to make that easier for both
> users and developers.) Again, I can live with it, but I think it's
> unfriendly.

This is only done via boot params or KConfig.

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