Messages in this thread | | | Date | Wed, 27 Mar 2019 05:57:07 +1100 (AEDT) | From | James Morris <> | Subject | Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down |
| |
On Mon, 25 Mar 2019, Andy Lutomirski wrote:
> A while back, I suggested an approach to actually make this stuff > mergeable: submit a patch series that adds lockdown mode, enables it > by command line option (and maybe sysctl) *only* and has either no > effect or only a token effect. Then we can add actual features to > lockdown mode one at a time and review them separately.
This makes sense to me.
> > And I'm going to complain loudly unless two things change about this > whole thing: > > 1. Lockdown mode becomes three states, not a boolean. The states are: > no lockdown, best-effort-to-protect-kernel-integrity, and > best-effort-to-protect-kernel-secrecy-and-integrity. And this BPF > mess illustrates why: most users will really strongly object to > turning off BPF when they actually just want to protect kernel > integrity. And as far as I know, things like Secure Boot policy will > mostly care about integrity, not secrecy, and tracing and such should > work on a normal locked-down kernel. So I think we need this knob.
Another approach would be to make this entirely policy based:
- Assign an ID to each lockdown point - Implement a policy mechanism where each ID is mapped to 0 or 1 - Allow this policy to be specified statically or dynamically
So,
kernel_is_locked_down("ioperm")
becomes
kernel_is_locked_down(LOCKDOWN_IOPERM)
and this function checks e.g.
if (lockdown_polcy[id]) { fail or warn; }
Thoughts?
> 2. All the proponents of this series, and the documentation, needs to > document that it's best effort. There will always be security bugs, > and there will always be things we miss.
Right. Maintaining this feature will be an ongoing effort, and if its not actively maintained, it will bitrot and become useless.
-- James Morris <jmorris@namei.org>
| |