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: <1351763954.2391.37.camel@dabdike.int.hansenpartnership.com>
Date:	Thu, 01 Nov 2012 09:59:14 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Jiri Kosina <jkosina@...e.cz>
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, 2012-11-01 at 10:45 +0100, Jiri Kosina wrote:
> 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.

James

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