linux-kernel - Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default LSM stack ordering

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:   Tue, 18 Oct 2022 15:31:09 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Casey Schaufler <casey@...aufler-ca.com>,
        Nicolas Iooss <nicolas.iooss@....org>,
        Mickaël Salaün <mic@...ikod.net>,
        James Morris <jmorris@...ei.org>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default
 LSM stack ordering

On Tue, Oct 18, 2022 at 1:55 AM Kees Cook <keescook@...omium.org> wrote:
> On Mon, Oct 17, 2022 at 09:45:21PM -0400, Paul Moore wrote:
> > The code sorta cares about ordering, at least to the extent that the
> > LSMs will behave differently depending on the ordering, e.g. a LSM
>
> Right -- this is why I've been so uncomfortable with allowing
> arbitrarily reordering of the LSM list from lsm=. There are orderings we
> know work, and others may have undesirable side-effects. I'd much rather
> the kernel be specific about the order.

At this point in the ongoing process of LSM stacking I'd much rather
we focus on documenting what we know to work and what is known to be
problematic without placing any restrictions on the ordering.  I
believe there are going to be too many "good" combinations to settle
on one single supported ordering; perhaps at some point in the future
we can agree on what that ordering should be, but I think there are
still too many changes in the foreseeable future to settle on an
ordering now.

> > I personally would like to preserve the existing concept where "built"
> > does *not* equate to "enabled" by default.
>
> Yup, understood. I didn't think I was going to win over anyone on that
> one, but figured I'd just point it out again. ;)

Fair enough.

> > > I *still* think there should be a way to leave ordering alone and have
> > > separate enable/disable control.
> >
> > My current opinion is that enabling a LSM and specifying its place in
> > an ordered list are one in the same.  The way LSM stacking as
> > currently done almost requires the ability to specify an order if an
> > admin is trying to meet an security relevant operation visibility
> > goal.
>
> As in an admin wants to see selinux rejections instead of loadpin
> rejections for a blocked module loading?

When I wrote my response I was thinking more of the BPF LSM, any
future LSMs that might be merged upstream, and the myriad of security
requirements admins must meet both now and in the future.

> > We can have defaults, like we do know, but I'm in no hurry to remove
> > the ability to allow admins to change the ordering at boot time.
>
> My concern is with new LSMs vs the build system. A system builder will
> be prompted for a new CONFIG_SECURITY_SHINY, but won't be prompted
> about making changes to CONFIG_LSM to include it.

I would argue that if an admin/builder doesn't understand what a shiny
new LSM does, they shouldn't be enabling that shiny new LSM.  Adding
new, potentially restrictive, controls to your kernel build without a
basic understanding of those controls is a recipe for disaster and I
try to avoid recommending disaster as a planned course of action :)

-- 
paul-moore.com