Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down

From: James Morris
Date: Tue Mar 26 2019 - 14:57:38 EST


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@xxxxxxxxx>