[lkml]   [2019]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down
On Tue, 26 Mar 2019, Andy Lutomirski wrote:

> >
> > 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.

OTOH, this seems like a combination of mechanism and policy. The 3 modes
are a help here, but I wonder if they may be too coarse grained still,
e.g. if someone wants to allow a specific mechanism according to their own
threat model and mitigations.

Secure boot gives you some assurance of the static state of the system at
boot time, and lockdown is certainly useful (with or without secure boot),
but it's not a complete solution to runtime kernel integrity protection by
any stretch of the imagination. I'm concerned about it being perceived as

I'm not sure how to think about it architecturally and how it fits as such
in the mainline kernel.

James Morris

 \ /
  Last update: 2019-03-28 04:17    [W:0.050 / U:4.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site