On 10/12/2018 04:31 AM, Jordan Glover wrote:

Sent with ProtonMail Secure Email.

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

quoted

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.

possibly, though that was proposed with a config patchset different than
the current proposal.

quoted

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?

what about a special marker like "+" which means the string is addative
;)

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

quoted

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 :)

:)

Maybe but I am not the only one who is asking for it, and the majority of
the user bases I represent don't have this requirement. But with my distro
hat on it really is a requirement for a distro that wants to enable
users to have access to every lsm, but have a sane default set that
can be supported.

Its really not an insane security policy that new security measures
are vetted before they are enabled.

quoted

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