On Wed, May 22, 2019 at 9:49 AM Matthew Garrett <mj...@google.com> wrote: > > On Tue, May 21, 2019 at 7:40 PM James Morris <jmor...@namei.org> wrote: > > An LSM could also potentially implement its own policy for the hook. > > That was my plan. Right now the hook just gets an ASCII description of > the reason for the lockdown - that seems suboptimal for cases like > SELinux. What information would you want? My initial thinking was to > just have a stable enum of lockdown reasons that's in the UAPI headers > and then let other LSM tooling consume that, but I haven't spent > enough time with the internals of SELinux to know if there'd be a more > attractive solution.
I may be in the minority here, but I see this issue as a significant downside of making lockdown more flexible. If we stick with just "this may violate integrity" and "this may violate confidentiality", then the ABI surface is nice and narrow. If we start having a big uapi list of things that might qualify for lockdown, we need to worry about compatibility issues. This isn't purely theoretical. Lockdown has some interesting interactions with eBPF. I don't want to be in a situation where v1 of lockdown has a few eBPF hooks, but a later update improves the eBPF vs lockdown interaction so that you can do more with eBPF on a locked down kernel. But now any such change has to worry about breaking the lockdown LSM ABI. And I still think it would be nice to have some credible use case for a more fine grained policy than just the tri-state. Having a lockdown policy of "may not violate kernel confidentiality except using kprobes" may be convenient, but it's also basically worthless, since kernel confidentiality is gone. All this being said, I do see one big benefit for LSM integration: SELinux or another LSM could allow certain privileged tasks to bypass lockdown. This seems fine, except that there's potential nastiness where current->cred isn't actually a valid thing to look at in the current context. So I guess my proposal is: use LSM, but make the hook very coarse grained: int security_violate_confidentiality(const struct cred *) and int security_violate_integrity(const struct cred *). --Andy