On 9/13/2018 4:51 PM, Kees Cook wrote: > On Thu, Sep 13, 2018 at 4:32 PM, John Johansen > <john.johansen@xxxxxxxxxxxxx> wrote: >> On 09/13/2018 04:06 PM, Kees Cook wrote: >>> - what order should any stacking happen? Makefile? security=? >>> >> Preferably not. For the single LSM we have the ability to choose the default LSM, ideally we let the distro decide in the Kconfig and the user with security=... > I can't find a non-crazy way to do this in Kconfig. Right now, if I > threw out all the _DEFAULT stuff, I could do: > > config SECURITY_SELINUX_ENABLED > bool "SELinux LSM enabled at boot time" > depends on SECURITY_SELINUX > depends on !SECURITY_APPARMOR_ENABLED && !SECURITY_SMACK_ENABLED > default SECURITY_SELINUX > > config SECURITY_SMACK_ENABLED > bool "SMACK LSM enabled at boot time" > depends on SECURITY_SMACK > depends on !SECURITY_APPARMOR_ENABLED && !SECURITY_SELINUX_ENABLED > default SECURITY_SMACK > > config SECURITY_APPARMOR_ENABLED > bool "AppArmor LSM enabled at boot time" > depends on SECURITY_APPARMOR > depends on !SECURITY_SMACK_ENABLED && !SECURITY_SELINUX_ENABLED > default SECURITY_APPARMOR > > config SECURITY_TOMOYO_ENABLED > bool "TOMOYO LSM enabled at boot time" > depends on SECURITY_TOMOYO > default y if !SECURITY_SELINUX_ENABLED && > !SECURITY_SMACK_ENABLED && !SECURITY_APPARMOR_ENABLED > > config DEFAULT_SECURITY > string > default "selinux" if SECURITY_SELINUX_ENABLED > default "smack" if SECURITY_SMACK_ENABLED > default "apparmor" if SECURITY_APPARMOR_ENABLED > default "tomoyo" if SECURITY_TOMOYO_ENABLED > > (As before CONFIG_DEFAULT_SECURITY basically means the effective > "security=" contents. Reminder than Kconfig default are "first match", > so tomoyo would only happen if all others are not enabled by default.) > > But this doesn't provide a way for Kconfig to declare the ordering of > TOMOYO followed by SELinux. If we just declare ordering is a function > of the Makefile, then the above would work as expected. The > "conflicting major LSM" could be specified on "security=" and stacked > could be enabled with $lsm.enable=1 (or disabled). > > So, before we can really make a decision, I think we have to decide: > should ordering be arbitrary for even this level of stacking? Do we have a case where it matters? I know that I could write a module that would have issues if one hook got called and another didn't because because a precursor module hook failed. I don't think that any of the existing modules have this problem.
