‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook keescook@xxxxxxxxxxxx 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
