Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
From: Kees Cook <hidden>
Date: 2018-10-04 16:18:48
Also in:
linux-arch, linux-security-module, lkml
On Wed, Oct 3, 2018 at 10:56 PM, John Johansen [off-list ref] wrote:
On 10/03/2018 01:36 PM, Kees Cook wrote:quoted
I still think we should have all built LSMs enabled by default, with CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDERand 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.
quoted
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