Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/