On Wed, Oct 3, 2018 at 10:56 PM, John Johansen <john.johansen@xxxxxxxxxxxxx> wrote: > On 10/03/2018 01:36 PM, Kees Cook wrote: >> 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. >> 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
