Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 3:19 AM, John Johansen [off-list ref] wrote:

It isn't perfect but it manages consistency across distros as best as
can be achieved atm.

Its just a fact that some LSMs are not going to be built into some
kernels. The only way to deal with that is direct people to build
their own kernels.

The other major problem is that the current LSM stacking patches do
not deal with "extreme" stacking. So doing

lsm=+apparmor

(I am going to stick with the + syntax atm to avoid confusion between
adding and setting)

assuming apparmor is builtin will not necessarily get you apparmor if
another major lsm is enabled. Yes your specific proposal would as it
specifies it overrides the current major, except that ordering
important so if say landlock registers before apparmor, you may still
not get apparmor.

I think this will be solved with LSM_ORDER_LAST or something like that
Kees proposed.

You proposal does not provide a means to ensure you have only a
specific set of LSMs enabled. As an LSM not explicitly listed in lsm=
lsm=! may still be enabled. So the user is going to have to be aware
of the initial LSMs list if they are trying to guarentee a specific
security arrangement.

What about special marker like "!!" which will mean "this string is
explicit?

lsm=!!,apparmor

will enable apparmor and disable everything else.

lsm=!!,!apparmor or lsm=!!

will set the string empty and disable everything.

"!!" in "CONFIG_LSM" will take precedence over "!!" in "lsm=" which
will make "lsm=" totally ignored. This way distro could lock specific
lsm set which isn't possible with current approach.

CONFIG_LSM=!!,yama,loadpin,integrity,apparmor

This violates one of the hard asks, and I will tell you that this will
just mean there is going to be some distro patching to make sure it
exists.

I think I can quess who will make those patches :)

The current explicit list is more consistent, and it is amenable to
being extended with + or ! as selective add/remove so we are not
locked into only supporting an explicit list.

Jordan