linux-kernel - Re: Linux Firmware Signing

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: <20150829015650.GL8051@wotan.suse.de>
Date:	Sat, 29 Aug 2015 03:56:50 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	"Roberts, William C" <william.c.roberts@...el.com>
Cc:	Paul Moore <paul@...l-moore.com>,
	David Woodhouse <dwmw2@...radead.org>,
	David Howells <dhowells@...hat.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Andy Lutomirski <luto@...capital.net>,
	Kees Cook <keescook@...omium.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
	"serge@...lyn.com" <serge@...lyn.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Eric Paris <eparis@...isplace.org>,
	"selinux@...ho.nsa.gov" <selinux@...ho.nsa.gov>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	"Schaufler, Casey" <casey.schaufler@...el.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Peter Jones <pjones@...hat.com>, Takashi Iwai <tiwai@...e.de>,
	Ming Lei <ming.lei@...onical.com>, Joey Lee <jlee@...e.de>,
	Vojtech Pavlík <vojtech@...e.com>,
	Kyle McMartin <kyle@...nel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Johannes Berg <johannes@...solutions.net>
Subject: Re: Linux Firmware Signing

On Fri, Aug 28, 2015 at 11:20:10AM +0000, Roberts, William C wrote:
> > -----Original Message-----
> > From: Paul Moore [mailto:paul@...l-moore.com]
> > 
> > While I question the usefulness of a SELinux policy signature in the general case,
> > there are some situations where it might make sense, e.g. embedded systems
> > with no post-build customizations, and I'm not opposed to added a signature to
> > the policy file for that reason.
> 
> Even triggered updates make sense, since you can at least have some form of trust
> of where that binary policy came from. 

The problem that Paul describes stems from the requirement of such trust
needing post-boot / install / setup keys.  It may be possible for an
environment to exist where there's a food chain that enables some CA's to
easily hand out keys to each install, but that seems impractical. This is why
Paul had mentioned the Machine Owner Key (MOK) thing.

> > However, I haven't given any serious thought yet to how we would structure the
> > new blob format so as to support both signed/unsigned policies as well as
> > existing policies which predate any PKCS #7 changes.
> > 
> 
> Huh, not following? Perhaps, I am not following what your laying down here.
> 
>  Right now there is no signing on the selinux policy file. We should be able
> to just use the firmware signing api's as is (I have not looked on linux-next yet)

Nitpick: its the system_verify_data() API, the fw signing stuff will make use
of this API as well.

> to unpack the blob.

Nitpick: to verify the data.

> In the case of falling back to loading an unsigned blob, we could do it ala kernel
> module style. If it fails do to invalid format fall back to attempting to read it as a straight policy file.
> If it fails on signature verification, we could still unpack it and pass it on. So you would want to 
> be able to control if the signed unpacking from pkcs7 fails, whether or not its fatal.
> 
> We would also likely want to convey this state, the ability to change this setting to userspace in a 
> Controlled fashion via selinuxfs. Ie I would want to know that I can load modules without valid signatures,
> And that my current policy file is in fact invalid or valid.

Sure that would work. Its how the module stuff can work in permissive mode.
We'd embrace the same practice for permissive fw signing as well.

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