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: <55088CEC.2010109@collabora.co.uk>
Date:	Tue, 17 Mar 2015 20:22:04 +0000
From:	Simon McVittie <simon.mcvittie@...labora.co.uk>
To:	Kees Cook <keescook@...omium.org>,
	Matthew Garrett <matthew.garrett@...ula.com>
CC:	"gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
	"serge@...lyn.com" <serge@...lyn.com>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"hpa@...or.com" <hpa@...or.com>
Subject: Re: Trusted kernel patchset

On 16/03/15 21:29, Kees Cook wrote:
> I really think "trusted" is the right term here. It's about as
> accurate as possible for what this flag means.

A subtlety that might make this clearer: there isn't really such a thing
as "trusted" in isolation, only "trusted by..." a specific other party;
and in this case, as far as I can see, the intended meaning is  that
lower layers (firmware and/or bootloader) have been configured to trust
this particular kernel.

It doesn't mean "user-space can trust me not to do bad things", because
any kernel, malicious or otherwise, could indeed easily claim that; and
if it is lying, what is user-space going to do about it anyway? Rather,
it means "the firmware is trusting me not to do things it would consider
bad".

I assume the intention isn't that it will make privileged bits of
userland be more careful to avoid breaking this trust assumption,
because the point of this patchset seems to be to make it impossible
(modulo bugs) for userland to do that.

Is the intention instead that it will make privileged bits of userland
more careful to avoid breaking the trust chain in ways that would "fail
safe" by refusing to boot?

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ