On Tue, Mar 26, 2019 at 11:57 AM James Morris <jmorris@xxxxxxxxx> wrote:
>
> 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?
I'm concerned that this gives too much useless flexibility to
administrators and user code in general. If you can break kernel
integrity, you can break kernel integrity -- it shouldn't really
matter *how* you break it.
--Andy
