On Wed, 3 Oct 2018, Kees Cook wrote: > On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@xxxxxxxxx> wrote: > > On Wed, 3 Oct 2018, Kees Cook wrote: > > > > - All LSMs which are built are NOT enabled by default > > > > - You specify enablement and order via a Kconfig: > > > > CONFIG_LSM="selinux,yama" > > > > - This can be entirely overridden by a boot param: > > > > lsm="apparmor,landlock" > > This doesn't work with how SELinux and AppArmor do their bootparams, > unfortunately. (And Paul and Stephen have expressed that the > documented selinux on/off must continue to work.) For example, let's > say you've built an Ubuntu kernel with: > > CONFIG_SELINUX=y > ... > CONFIG_LSM="yama,apparmor" > > (i.e. you want SELinux available, but not enabled, so it's left out of > CONFIG_LSM) > > Then someone boots the system with: > > selinux=1 security=selinux > > In what order does selinux get initialized relative to yama? > (apparmor, flagged as a "legacy major", would have been disabled by > the "security=" not matching it.) It doesn't, it needs to be specified in one place. Distros will need to update boot parameter handling for this kernel onwards. Otherwise, we will need to carry this confusing mess forward forever. > The LSM order needs to be defined externally to enablement because > something may become enabled when not listed in the order. > > Now, maybe I misunderstood your earlier suggestion, and what you meant > was to do something like: > > CONFIG_LSM="yama,apparmor,!selinux" > > to mean "put selinux here in the order, but don't enable it". Then the > problem becomes what happens to an LSM that has been built in but not > listed in CONFIG_LSM? In my most recent suggestion, there is no '!' disablement, just enablement. If an LSM is not listed in CONFIG_LSM="", it's not enabled. > Related to that, this means that when new LSMs are added, they will > need to be added to any custom CONFIG_LSM= or lsm= parameters. If > that's really how we have to go, I'll accept it, but I think it's a > bit unfriendly. :P If you want to enable them, yes. How is this different to adding new mount options as new fs features become available? > Another reason I don't like it is because it requires users to know > about all the LSMs to make changes. One LSM can't be added/removed > without specifying ALL of the LSMs. (i.e. there is no trivial way to > enable/disable a single LSM without it growing its own enable/disable > code as in SELinux/AppArmor. I'd hoped to make that easier for both > users and developers.) Again, I can live with it, but I think it's > unfriendly. This is only done via boot params or KConfig. -- James Morris <jmorris@xxxxxxxxx>
