Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20210222150608.808146-1-mic@digikod.net> <20210222150608.808146-2-mic@digikod.net>
 <51725b44-bc40-0205-8583-285d3b35b5ca@schaufler-ca.com> <ee461f8d-a02d-0782-8f31-691853a57f00@digikod.net>
 <7b67163a-9de1-313f-5b5a-8c720cef9b73@schaufler-ca.com> <CAJfZ7=n5FOxHXMLRrDQ3F-kDqbYngNoYKcz6_PWi1rPa0_8WpA@mail.gmail.com>
 <3b97e25b-303c-d732-3e5d-f1b1a446e090@schaufler-ca.com> <202210171111.21E3983165@keescook>
In-Reply-To: <202210171111.21E3983165@keescook>
From:   Paul Moore <paul@paul-moore.com>
Date:   Mon, 17 Oct 2022 21:45:21 -0400
Message-ID: <CAHC9VhTTKpesvjnc_233x+wG1BvXyup9nM4Dv2h1953zXAvU3A@mail.gmail.com>
Subject: Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default
 LSM stack ordering
To:     Kees Cook <keescook@chromium.org>
Cc:     Casey Schaufler <casey@schaufler-ca.com>,
        Nicolas Iooss <nicolas.iooss@m4x.org>,
        =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= <mic@digikod.net>,
        James Morris <jmorris@namei.org>,
        "Serge E . Hallyn" <serge@hallyn.com>,
        linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= <mic@linux.microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Oct 17, 2022 at 3:29 PM Kees Cook <keescook@chromium.org> wrote:
>
> [*double thread necromancy*]

Yikes!  This is some pretty serious mail thread crime ...

> On Mon, Feb 22, 2021 at 02:46:24PM -0800, Casey Schaufler wrote:
> > It wouldn't. But compiling the new LSM mynewlsm doesn't add it to
> > the list, either. Today no one should expect a LSM to be active if
> > it hasn't been added to the CONFIG_LSM list. The proposed addition
> > of CONFIG_LSM_AUTO would change that. "make oldconfig" would add
> > security modules that are built to the list. This is unnecessary
> > since whoever changed CONFIG_SECURITY_MYNEWLSM to "y" could easily
> > have added it to CONFIG_LSM. In the right place.
>
> Having CONFIG_LSM/lsm= is to support the migration away from having a
> "default major LSM", but still provide a way to separate "built" vs
> "enabled". As such, it needs to provide ordering. (So we have three
> concepts here: "built" at all, "enabled" by default, and in a specific
> "order".) And not being listed in CONFIG_LSM/lsm= means an LSM is
> disabled.
>
> I don't disagree about "anyone who enables a new LSM config can add it to
> CONFIG_LSM", but really I think the question is why require an _ordering_
> choice. Most distros and builders don't care beyond having the current
> "default major LSM" come first, which leaves only the "enabled by
> default" choice.

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
lower in the priority order might never "see" an operation if a higher
priority LSM rejects the operation.  Yes, it's an implementation
quirk, but I'm not sure I want to start messing with the
fail-on-first-error logic right now.  Maybe once we've got the LSM
layer fully stackable and we've gotten past the initial support
nightmare of that we can revisit this idea.

> I personally think it's reasonable that a "built" LSM be "enabled" by
> default, however, this is not universally held to be true. :)

I personally would like to preserve the existing concept where "built"
does *not* equate to "enabled" by default.

> 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 is
currently done almost requires the ability to specify an order if an
admin is trying to meet an security relevant operation visibility
goal.

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.

-- 
paul-moore.com