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]

Date:   Thu, 4 Oct 2018 07:34:38 +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 11:28 AM, James Morris <jmorris@...ei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@...ei.org> wrote:
> >> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> >> To me a list like
> >> >>   lsm.enable=X,Y,Z
> >> >
> >> > What about even simpler:
> >> >
> >> > lsm=selinux,!apparmor,yama
> >>
> >> We're going to have lsm.order=, so I'd like to keep it with a dot
> >> separator (this makes it more like module parameters, too). You want
> >> to mix enable/disable in the same string? That implies you'd want
> >> implicit enabling (i.e. it complements the builtin enabling), which is
> >> opposite from what John wanted.
> >>
> >
> > Why can't this be the order as well?
> 
> That was covered extensively in the earlier threads. It boils down to
> making sure we do not create a pattern of leaving LSMs disabled by
> default when they are added to the kernel. The v1 series used
> security= like this:
> 
> +       security=       [SECURITY] An ordered comma-separated list of
> +                       security modules to attempt to enable at boot. If
> +                       this boot parameter is not specified, only the
> +                       security modules asking for initialization will be
> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
> +                       or invalid security modules will be ignored. The
> +                       capability module is always loaded first, without
> +                       regard to this parameter.
> 
> This meant booting "security=apparmor" would disable all the other
> LSMs, which wasn't friendly at all. So "security=" was left alone (to
> leave it to only select the "major" LSM: all major LSMs not matching
> "security=" would be disabled). So I proposed "lsm.order=" to specify
> the order things were going to be initialized in, but to avoid kernels
> booting with newly added LSMs forced-off due to not being listed in
> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
> (i.e. anything missing from lsm.order would then follow their order in
> CONFIG_LSM_ORDER, and anything missing there would fall back to
> link-time ordering.) However, then the objection was raised that this
> didn't provide a way to explicitly disable an LSM. So I proposed
> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
> CONFIG_LSM_DISABLE.

Ok, but it may end up being clearer, simpler, and thus more secure to just 
have a single way to configure LSM.

For example:

  - 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"

And that's it.

Of course, capabilities is always enabled and not be visible to kconfig or 
boot params.


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