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-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
