On Mon, Oct 17, 2022 at 3:29 PM Kees Cook [off-list ref] 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:

quoted

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