Thread (92 messages) 92 messages, 7 authors, 2018-10-08

Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter

From: Kees Cook <hidden>
Date: 2018-10-04 16:18:48
Also in: linux-arch, linux-doc, lkml

On Wed, Oct 3, 2018 at 10:56 PM, John Johansen
[off-list ref] wrote:
On 10/03/2018 01:36 PM, Kees Cook wrote:
quoted
I still think we should have all built LSMs enabled by default, with
CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER
and this as a distro ubuntu does not want.
Ubuntu wants to make yes available by building them in, but does NOT
want all the LSM enabled by default, not even necessarily all minor LSMs.

As a distro we want a supported set as default, and users can opt-in
to new LSMs. If a new LSM comes along we don't want it enabled by
default, which happens Using the lsm disable approach.
Okay, but order still matters. Where, in the order, should a disabled
LSM go? It seems like the friendliest approach for an end-user would
be to do something like

lsm=+landlock

and it all works correctly. That user doesn't need to know about
ordering or the distro default LSMs. They just want to _add_ landlock.
They want all the other LSMs to still be present, and they want the
distro to have chosen where landlock is in the ordering.
quoted
I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
in, since it's just a way to disable all the other majors. I don't
like this because it will force LSMs to be disabled that don't need to
be once blob-sharing lands. The whole point of this series is to get
us away from fixed ordering and thinking about "major" vs "minor" and
towards "exclusive" or not, where we can continue to slowly chip away
at exclusivity without breaking anything.
sure we definitely want to get away form "major" vs "minor" and in
generally even exclusive, except where to LSMs just can't live
with each other.

But that doesn't mean dropping something like default security. The
mistake with the current DEFAULT_SECURITY was that it only applied
to major LSMs, not the minor ones.
Right, we need to expand it to include a full description of ordering
and enablement.

How about this:

CONFIG_LSM specifies order and enablement status. For example:

CONFIG_LSM=yama,loadpin,apparmor,!selinux

This means init order is yama, loadpin, apparmor, selinux, but selinux
is disabled. Anything not listed in CONFIG_LSM but built in will be
disabled and ordered in link-order. (i.e. an implicit trailing
"!smack,!tomoyo".)

Then we add "lsm=" which understands modifiers "-", and "+".
"lsm=-apparmor,+selinux" wouldn't change ordering, but would disable
apparmor and enable selinux. "lsm=smack,loadpin" would enable only
smack and loadpin, in that order and disable everything else.

I don't want to overload "security=", but we can if we want. It would
be as above, but a trailing comma would be needed to trigger the
"ordering" behavior. e.g. "security=selinux" would disable all other
majors (retaining the current behavior), but "security=selinux," would
disable all other LSMs.

-Kees

-- 
Kees Cook
Pixel Security
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help