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>
