linux-kernel - Re: Trusted kernel patchset

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]

Date:	Tue, 17 Mar 2015 17:48:11 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Kees Cook <keescook@...omium.org>
Cc:	Matthew Garrett <matthew.garrett@...ula.com>,
	"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

> I really think "trusted" is the right term here. It's about as
> accurate as possible for what this flag means. In the same way that

verified perhaps - however its bikeshedding territory and I don't care
that much 8)

> > I'm kind of torn on this - yes, there are deployment scenarios where
> > hibernation can be used to circumvent the restrictions, but there are
> > also scenarios where that can be avoided (eg, the bootloader verifies
> > some state with respect to the hibernation image).
> 
> We have no system yet to validate hibernation images, so it's correct
> to disable hibernation images that lack validation (which is all of
> them).

Agreed.

> > Good point. In general there's also the risk that GPIOs may be used for
> > features like TPM physical presence detection, so exposing those to
> > userspace does seem like a bad idea.
> 
> Possibly the SPI driver too.

SPI and I2C from userspace are both good candidates. The devices are not
DMA but often it does include power management ICs. On many phones it
would however break assorted evilware binary userspace drivers not that I
care.

> I still say that a trusted kernel includes its boot parameters. This
> is true in the Chrome OS case, as parameters are part of the verified
> kernel boot block, but it could be a concern for someone who has built
> a grub-based CDROM or something and didn't lock the grub menu down. I
> think, though, that those things need to be part of documentation, not
> code, as this point.

I think we need to clearly document the assumption. Who owns validating
boot parameters, is there an assumption that boot parameters are safe, do
we need a whitelist to make it user friendly (eg turning off rhgb quiet
and adding debug init=/bin/sh every time systemd s**ts itself).

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