lkml.org 
[lkml]   [2012]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Second attempt at kernel secure boot support
On Thu, 1 Nov 2012, James Bottomley wrote:

> > > I'm actually just struggling to understand the use case for these more
> > > esoteric protections.
> >
> > I believe the real point is drawing a clear line between trusted and
> > untrusted (with root being userspace, hence implicitly untrusted), and
> > disallowing "legitimate crossing" of this line.
>
> But that doesn't really help me: untrusted root is an oxymoron. I get
> capability separated systems, where you invest trust in layers and you
> make each layer small and verifiable, so you have a granular trust
> policy you build up. I really don't understand the use case for trying
> to remove a small portion of trust from the huge trust domain of root
> and then doing a massive amount of fixup around the edges because
> there's leaks all over the place from the trust that root still has. It
> all seems to be a bit backwards. If you just begin with the capability
> separated granular system, I don't see why it doesn't all just work with
> what we have today.

Please don't get me wrong -- I personally don't believe in the secure boot
stuff at all.

But if you take the secure/trusted boot as a basic paradigma, then you
really need the separation.
In such model, the root is untrusted, exactly because the code running
under those privileges hasn't been signed, period. If you allow such code
to modify the trusted/signed code, you just basically violate the complete
model, rendering it completely moot.

--
Jiri Kosina
SUSE Labs


\
 
 \ /
  Last update: 2012-11-01 11:41    [W:0.396 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site