Messages in this thread | | | Date | Thu, 23 May 2019 04:05:56 +1000 (AEST) | From | James Morris <> | Subject | Re: [RFC] Turn lockdown into an LSM |
| |
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 <jmorris@namei.org>
| |