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]

Message-ID: <20150316200707.21cfa166@lxorguk.ukuu.org.uk>
Date:	Mon, 16 Mar 2015 20:07:07 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Matthew Garrett <matthew.garrett@...ula.com>
Cc:	"keescook@...omium.org" <keescook@...omium.org>,
	"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

> > Also the boot loader should be measuring the kernel before it runs it,
> > thats how it knows the signature is correct.
> 
> That's one implementation. Another is the kernel being stored on
> non-volatile media.

Same thing. One is just an optimisation ("const") 8)

> form of trusted boot chain can enable the lockdowns while still within
> the trusted codebase. If you want to prove trustworthiness then you're
> still going to need something like TPM-based attestation.

Makes sense.

On hibernate I think eventually it has to come down to the bootloader
and TPM signatures but to an extent it depends if you are getting into
the territory of protecting a machine from its supposed owner, or just
from passing malware.

> > What you don't document is the assumption about how the kernel boot
> > parameters are handled. A large number of boot parameters allow arbitrary
> > I/O access or allow code execution if used with skill and cunning.
> 
> Things that spring to mind here:

Ok I was more assuming it was going to be "the bootloader only allows you
to do ..." 

> 1) The ability to disable IOMMUs (some handwaving about the number of
> machines that still don't have IOMMUs because security is a perfectly
> reasonable thing to perform product differentiation on I guess?)
> 2) Your previous concerns about being able to manipulate the memory map
> in hostile ways
> 3) Drivers that allow users to tell the kernel devices exist at
> arbitrary memory addresses and then benefit from probe routines that
> write blindly

That's the main one

4) firewire and other interfaces that allow you to leave debug features
enabled. Firewire is the obvious one to me.

5) Manipulating firmware (acpi table replacements, alternative and extra
devicetree nodes etc)

> especially worried about in category (3) are the earlyprintk ones, but
> obviously there's a bunch of old drivers that allow arbitrary addresses
> to be passed and cleaning those up would be worth it.

When you get to devicetree or non x86 stuff there are quite a few modern
ones that do pretty much the same I think.

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/