[PATCH security-next v5 00/30] LSM: Explict ordering

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook at chromium.org> wrote:

> On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook keescook at chromium.org wrote:
>
> > v5:
> >
> > -   redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> > -   dropped various Reviewed-bys due to rather large refactoring
>
> Here's a tl;dr of the behavioral changes...
>
> Right now, we have:
>
> -   hard-coded special LSM: capability which cannot be disabled.
> -   hard-coded "minor" LSMs: they are enabled in a static order based on
>     whether they are built into the kernel or not: yama, loadpin.
>
> -   a single LSM without a specified order because it only uses the
>     early-init position: integrity.
>
> -   "major" LSMs that are selected via CONFIG_DEFAULT_SECURITY= or
>     "security=" boot param.
>
> -   SELinux and AppArmor each can enable/disable themselves via
>     CONFIG_..._BOOTPARAM_VALUE= and selinux=/apparmor=.
>
>     So, right now, systems will have all the minor LSMs and integrity
>     initialized if they are built into the kernel without any way to
>     control their order or disable them at boot time. To select a major
>     LSM, the pattern is:
>
>     selinux=1 security=selinux
>
>     Note that both are used here because if you built with
>     CONFIG_SELINUX_BOOTPARAM_VALUE=0 and CONFIG_DEFAULT_SECURITY=apparmor,
>     just booting with "security=selinux" just disables AppArmor but
>     SELinux stays disabled. So the documented way to switch majors is with
>     "selinux=1 security=selinux". However Tomoyo and Smack do not have
>     separate enable/disable logic. They will work fine with just
>     "security=smack".
>
>     Now, in order to gain arbitrary LSM ordering, this series introduces
>     CONFIG_LSM= (to replace CONFIG_DEFAULT_SECURITY=) and "lsm=" (to
>     replace "security="). Note that "security=" has not been removed -- it
>     will still work. Mixing it with "lsm=" can lead to situations where
>     "security=" becomes effectively ignored, though.
>
>     In the rest of this I'm going to ignore capability: it will always be
>     first and it will always be enabled.
>
>     Assuming that all LSMs are built in (e.g. yama, loadpin, selinux,
>     smack, tomoyo, apparmor, integrity), here are the changes:
>
>     To choose the "default major LSM" of AppArmor before:
>     CONFIG_DEFAULT_SECURITY=apparmor
>
>     To choose the "default major LSM" of AppArmor without extreme stacking now:
>     CONFIG_LSM=yama,loadpin,integrity,apparmor
>
>     To choose the "default major LSM" of AppArmor with future extreme stacking now:
>     CONFIG_LSM=yama,loadpin,integrity,apparmor,tomoyo,selinux,smack
>
>     Whichever exclusive LSM is listed first will be the first to attempt
>     initialization. Any non-conflicting LSMs following it will initialize
>     too.
>
>     This means a distro can disable the "blob-sharing" behavior by just
>     providing a CONFIG_LSM= that includes a single major LSM.
>
>     To switch to SELinux at boot time with
>     "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>     work:
>
>     selinux=1 security=selinux
>
>     This will work still, since it will enable selinux (selinux=1) and
>     disable all other major LSMs (security=selinux).
>
>     The new way to enable selinux would be using
>     "lsm=yama,loadpin,integrity,selinux".
>

It seems to me that legacy way is more user friendly than the new one.
AppArmor and SElinux are households names but the rest may be enigmatic
for most users and the need for explicit passing them all may be
troublesome. Especially when the new ones like sara,landlock or cows :)
will be incoming. Moreover to knew what you have to pass there, you need
to look at CONFIG_LSM in kernel config (which will vary across distros
and also mean copy-paste from the web source may won't work as expected)
which again most users don't do.

I think there is risk that users will end up with "lsm=selinux" without
realizing that they may disable something along the way.

I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
below assumptions:

I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
stacking it will also remove the other major (explicit) lsm from it.

II. lsm="!$lsm" will remove "$lsm" from the string.

III. If "$lsm" already exist in the string, it's moved at the end of it
(this will cover ordering).

Examples:

1. Without extreme stacking.

a) Enable selinux, disable apparmor and leave the rest untouched.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux = yama,loadpin,integrity,selinux

b) Enable selinux, disable apparmor and disable loadpin.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!loadpin = yama,integrity,selinux


2. With extreme stacking.

a) Enable selinux, disable apparmor and leave the rest untouched.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!apparmor = yama,loadpin,integrity,selinux

b) Enable selinux, disable apparmor and disable loadpin.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!apparmor,!loadpin = yama,integrity,selinux

c) Enable selinux and order it after apparmor.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux = yama,loadpin,integrity,apparmor,selinux

d) Enable selinux and order it before apparmor.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,apparmor = yama,loadpin,integrity,selinux,apparmor


IMO above will be easier to handle for users. At worst case with
full ordering all existing lsm's it will look the same as what
Kees proposes but I assume that ordering is rather for more
advanced people.

It's possible that something lime this was discussed already
but without full examples it was hard to me for tracking things.

Jordan