On Wed, 22 May 2019, Andy Lutomirski wrote: > 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.
This is an important point, but there's also "can't use any lockdown features because the admin might need to use kprobes". I mention a use-case below. I think it's fine (and probably preferred) to keep the default behavior tri-state and allow LSMs to implement finer-grained policies. > 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. Some environments _need_ a "break glass" option, and a well-defined policy (e.g. an SELinux domain which can only be entered via serial console, with 2FA or JIT credentials) to selectively un-lock the kernel lockdown in production would mean the difference between having a fleet of millions of nodes 99.999% locked down vs 0%. > 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. Right. Can we identify any such cases in the current patchset? One option would be for the LSM to assign a default (untrusted/unknown) value for the subject and then apply policy as needed (e.g. allow or deny these). > 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 *). Perhaps security_kernel_unlock_* -- James Morris <jmor...@namei.org>