On Thu, Sep 13, 2018 at 5:52 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Thu, Sep 13, 2018 at 2:38 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > The infrastructure bits aren't really my concern; in fact I *like* > > that the infrastructure is always exercised, it makes > > testing/debugging easier. I also like the ability to limit the > > user/admin to one LSM at boot time to make support easier; my goal is > > to allow a distro to build support for multiple LSMs without also > > requiring that distro to support *stacked* LSMs > > I see your point, but as soon as SARA and Landlock appear, they'll have: > > depends on SECURITY_STACKING > > and then all distros will enable it and there will be no sensible > runtime way to manage it. If, instead, we make it entirely runtime > now, then a CONFIG can control the default state and we can provide > guidance to how SARA and Landlock should expose their "enable"ness. I question why SARA and LandLock require stacking. While some LSMs may benefit from stacking, e.g. Yama, traditionally each LSM has been able to stand on its own. I think this is a quality that should be preserved. > > (see my earlier > > comments about the difficulty in determining the source of a failed > > operation). > > Agreed. I would hope that audit could help for that case. *stare at blue sky* *also staring at blue sky* Audit can help, but it is independent of the LSMs and not a hard requirement for all, and even when it is enabled the config might not be suitable to provide enough information to be helpful in this case. -- paul moore www.paul-moore.com _______________________________________________ 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.
