On 2/6/2019 6:30 PM, Tetsuo Handa wrote: > Casey Schaufler wrote: >> On 2/6/2019 2:23 AM, Tetsuo Handa wrote: >>> But as I update the documentation ( https://tomoyo.osdn.jp/2.6/chapter-3.html.en#3.6 ), >>> I came to think that we should ignore security= parameter when lsm= parameter is specified. >>> >>> Currently, it is possible to enable TOMOYO and only one of SELinux/Smack/AppArmor. Therefore, >>> it is possible to disable only TOMOYO by specifying security=selinux when we want to enable >>> only SELinux, by specifying security=smack when we want to enable only Smack, by specifying >>> security=apparmor when we want to enable only AppArmor. That is, we can use security= parameter >>> in order to specify the other LSM module which should not be disabled. >>> >>> But when it becomes possible to enable TOMOYO and more than one of SELinux/Smack/AppArmor, >>> we will no longer be able to selectively disable one LSM module using security= parameter, for >>> security= parameter is intended for specifying only one LSM module which should be enabled. >>> That is, we will need to use lsm= parameter in order to selectively disable LSM modules. >> Yes. That is correct. The existing behavior of security= is maintained. > But the existing behavior of CONFIG_DEFAULT_SECURITY is not maintained. That's a developer interface, not a user interface. I realize that may be splitting hairs, but it had to change. > This might cause a problem like > > commit e5a3b95f581da62e2054ef79d3be2d383e9ed664 > Author: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > Date: Sat Feb 14 11:46:56 2009 +0900 > > TOMOYO: Don't create securityfs entries unless registered. > > TOMOYO should not create /sys/kernel/security/tomoyo/ interface unless > TOMOYO is registered. > > for Ubuntu users because Ubuntu kernels are built with > > CONFIG_SECURITY_SELINUX=y > CONFIG_SECURITY_SMACK=y > CONFIG_SECURITY_TOMOYO=y > CONFIG_SECURITY_APPARMOR=y > CONFIG_SECURITY_YAMA=y > CONFIG_DEFAULT_SECURITY="apparmor" > > . Due to CONFIG_DEFAULT_SECURITY="apparmor", majority of Ubuntu users are enabling > only AppArmor without explicitly specifying "security=apparmor". > > Currently default CONFIG_LSM setting is > > "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor" > > but Ubuntu kernels would have to be built with non-default CONFIG_LSM setting like > > "yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" > > in order to make sure that AppArmor is by default chosen for the LSM_FLAG_EXCLUSIVE module. Yes, and Yocto Project is likely to want Smack specified first. > Now that TOMOYO becomes a !LSM_FLAG_EXCLUSIVE module, not specifying "security=apparmor" will > automatically enable TOMOYO. And majority of Ubuntu users will unexpectedly encounter TOMOYO > messages. But removing "tomoyo" from CONFIG_LSM setting in order to save majority of Ubuntu > users from unexpectedly encountering TOMOYO messages also has a problem; Ubuntu users who want > to enable only TOMOYO from LSM_FLAG_LEGACY_MAJOR modules can specify "security=tomoyo", but > Ubuntu users who want to enable TOMOYO and one of SELinux,Smack,AppArmor (including syzbot) > will have to explicitly specify "lsm=" because "security=" can't allow enabling multiple > LSM_FLAG_LEGACY_MAJOR modules. I believe we got general buy in from Ubuntu, and I understand that the LSM list is awkward, but I don't see a rational alternate. I know that I played with a half dozen, and nothing was closer to maintaining the status quo. >> The new behavior of lsm= is provided to allow general handling of a list >> of security modules. It uses the same form of data as CONFIG_LSM. >> >>> Then, I think that it is straightforward (and easier to manage) to ignore security= parameter >>> when lsm= parameter is specified. >> That reduces flexibility somewhat. If I am debugging security modules >> I may want to use lsm= to specify the order while using security= to >> identify a specific exclusive module. I could do that using lsm= by >> itself, but habits die hard. > "lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would > have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order > to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time). > > Since "security=" can't be used for selectively enable/disable more than one of > SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the > better direction. And ignoring "security=" when "lsm=" is specified is easier to understand. I added Kees to the CC list. Kees, what to you think about ignoring security= if lsm= is specified? I'm ambivalent.
