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;
Date:   Mon, 17 Oct 2022 12:25:31 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Casey Schaufler <casey@schaufler-ca.com>
Cc:     Nicolas Iooss <nicolas.iooss@m4x.org>,
        =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= <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,
        =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= <mic@linux.microsoft.com>
Subject: Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default
 LSM stack ordering
Message-ID: <202210171111.21E3983165@keescook>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3b97e25b-303c-d732-3e5d-f1b1a446e090@schaufler-ca.com>
Precedence: bulk

[*double thread necromancy*]

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.

To review, security= currently only enables/disables apparmor, selinux,
smack, and tomoyo. It will go away once the full implementation of
stacking is finished.

I personally think it's reasonable that a "built" LSM be "enabled" by
default, however, this is not universally held to be true. :) The need
remains that enablement be configurable. The current solution here is
to add/remove it from CONFIG_LSM/lsm=. What remains problematic, though,
is a mismatch between lack of ordering causing disabling, but enabling
doesn't specify ordering. Ordering only matters for the legacy major
LSMs, which is controlled by CONFIG_DEFAULT_SECURITY_*.

Here is a reasonable overview of the main "lsm=" thread...
https://lore.kernel.org/all/CAGXu5jKqXNbEvPr1axQtGCCnWsGhDgjynW5u326mcx4vZ1oH8g@mail.gmail.com/
https://lore.kernel.org/all/abe03d09-4dcb-2b02-4102-5e108d617a42@canonical.com/
https://lore.kernel.org/all/CAGXu5jJtC1gkJ0ZKDFroL8UzvjiPfmC+6EsrzyB0j0oETdSQQg@mail.gmail.com/
https://lore.kernel.org/all/7741e4c1-cc54-4d04-a064-cb5388817058@canonical.com/
https://lore.kernel.org/all/CAGXu5jLKgrdhah-5TtAXDL-odbLGeyAUH2=PkAU769AkEnZFfQ@mail.gmail.com/
https://lore.kernel.org/all/5955f5ce-b803-4f58-8b07-54c291e33da5@canonical.com/
https://lore.kernel.org/all/CAGXu5jLBHN=YSs3Uh49bBJ1SRA1Km2UUD4j37GJJXiKhQq+KPA@mail.gmail.com/
https://lore.kernel.org/all/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@mail.gmail.com/
https://lore.kernel.org/all/88b0cc69-cd42-1798-6ce4-d3cfbbc79d83@canonical.com/
https://lore.kernel.org/all/alpine.LRH.2.21.1810051449110.2590@namei.org/

I *still* think there should be a way to leave ordering alone and have
separate enable/disable control. And I think the growth of additional
LSMs that need explicit ordering supports this proposal.

What has become clear is that allowing _ordering_ to be generically
mutable is a mistake (and we had hints of this due to the standing
exceptions for "capability"). How about making these changes:

1) make ordering be source/"built"-controlled (i.e. similar to what
   CONFIG_LSM_AUTO proposes)
2) have CONFIG_LSM/lsm= control only enable/disable and NOT ordering except
   for the "major" LSMs.
3) introduce "lsm=+foo,-bar" that will enable/disable the given LSMs without
   changing relative order.

I think of it like this. LSMs declare their ordering position (btw,
capability remains an exception to the existing logic, and this change
would begin to regularize it, IMO):

first:   capability (cannot be disabled)
early:   landlock,lockdown,yama,loadpin,safesetid,integrity
mutable: selinux,apparmor,smack,tomoyo
late:    bpf
last:    ...empty...

And "lsm=" can only change the order of the "mutable" ordering LSMs.

As an example:

Assuming The "built" order for all LSMs was defined as:
  capability,landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,apparmor,smack,tomoyo,bfp

If CONFIG_LSM was:      yama,integrity,apparmor,selinux,bpf,lockdown

a) without boot param
   result would be: lsm=capability,yama,integrity,lockdown,apparmor,selinux,bpf

b) with boot param: lsm=selinux,lockdown,yama
   result would be: lsm=capability,yama,lockdown,selinux

c) with boot param: lsm=-lockdown
   result would be: lsm=capability,yama,lockdown,integrity,apparmor,selinux,bpf

d) with boot param: lsm=+setsetid
   result would be: lsm=capability,yama,safesetid,integrity,lockdown,apparmor,selinux,bpf

Thoughts?

-- 
Kees Cook