lkml.org 
[lkml]   [2022]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default LSM stack ordering
[*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

\
 
 \ /
  Last update: 2022-10-17 21:29    [W:0.244 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site