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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1211011101240.6606@pobox.suse.cz>
Date:	Thu, 1 Nov 2012 11:06:04 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Oliver Neukum <oneukum@...e.de>,
	Chris Friesen <chris.friesen@...band.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/