On 2019/02/01 19:09, Dmitry Vyukov wrote: > Thanks for the explanations. > > Here is the change that I've come up with: > https://github.com/google/syzkaller/commit/aa53be276dc84aa8b3825b3416542447ff82b41a You are not going to apply this updated config to upstream kernels now, are you? Removing CONFIG_DEFAULT_SECURITY="apparmor" from configs used by upstream kernels will cause failing to enable AppArmor (unless security=apparmor is specified). I guess you can apply this updated config to linux-next kernels given that you replace CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor" with CONFIG_LSM="yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" so that AppArmor is enabled instead of SELinux. > > I've disabled CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER (it > actually looked like omitting a user-space loader that I don't have is > the right thing to do, but okay, it indeed does not with =y). > > For now I just enabled TOMOYO and SAFESETID. > I see the problem with making both linux-next and upstream work. If we > use a single config and lsm= cmdline argument, then on upstream all > kernels will use the same module (they won't understand lsm=). But if > we add security= then it will take precedence over lsm= on linux-next, > so we won't get stacked modules. Right. > > Let's go with (c) because I don't want an additional long-term maintenance cost. OK. > If I understand it correctly later we will need to replace: > security=selinux > security=smack > security=apparmor > > with: > lsm=yama,safesetid,integrity,selinux,tomoyo > lsm=yama,safesetid,integrity,smack,tomoyo > lsm=yama,safesetid,integrity,tomoyo,apparmor Yes. Thank you. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
