‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 11, 2018 7:57 PM, Kees Cook [off-list ref] wrote:

On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook keescook@chromium.org wrote:

quoted

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