linux-kernel - Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock

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: <CAGXu5jLapViSK-j08Tq8cCZodiZXFsXze71xFPg6MQhDWDHDAA@mail.gmail.com>
Date:   Thu, 13 Sep 2018 14:51:57 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Casey Schaufler <casey@...aufler-ca.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        James Morris <jmorris@...ei.org>,
        LKML <linux-kernel@...r.kernel.org>,
        SE Linux <selinux@...ho.nsa.gov>,
        John Johansen <john.johansen@...onical.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        "Schaufler, Casey" <casey.schaufler@...el.com>
Subject: Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock

On Thu, Sep 13, 2018 at 2:38 PM, Paul Moore <paul@...l-moore.com> wrote:
> The infrastructure bits aren't really my concern; in fact I *like*
> that the infrastructure is always exercised, it makes
> testing/debugging easier.  I also like the ability to limit the
> user/admin to one LSM at boot time to make support easier; my goal is
> to allow a distro to build support for multiple LSMs without also
> requiring that distro to support *stacked* LSMs

I see your point, but as soon as SARA and Landlock appear, they'll have:

    depends on SECURITY_STACKING

and then all distros will enable it and there will be no sensible
runtime way to manage it. If, instead, we make it entirely runtime
now, then a CONFIG can control the default state and we can provide
guidance to how SARA and Landlock should expose their "enable"ness.

At the very least, to avoid stacking now (i.e. TOMOYO being enabled
with another major LSM), we just do nothing. The existing code already
makes the existing major LSMs exclusive. Adding a stackable LSM would
need to just have its own "enable" flag (i.e. ignore
security_module_enable()), and then either check a runtime "is
stacking allowed?" flag or have new "depends on SECURITY_STACKING". (I
think the CONFIG will force distros into enabling it without any
runtime opt-out.)

> (see my earlier
> comments about the difficulty in determining the source of a failed
> operation).

Agreed. I would hope that audit could help for that case. *stare at blue sky*

-Kees

-- 
Kees Cook
Pixel Security