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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhRj4dRGVz9RmjxC9xsV_anKS+LHUW8f2UZ4H63N5J89Jw@mail.gmail.com>
Date:	Thu, 27 Aug 2015 19:46:09 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	David Howells <dhowells@...hat.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Andy Lutomirski <luto@...capital.net>,
	Kees Cook <keescook@...omium.org>,
	"Roberts, William C" <william.c.roberts@...el.com>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	linux-kernel@...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,
	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>,
	dwmw2@...radead.org, Ming Lei <ming.lei@...onical.com>,
	Joey Lee <jlee@...e.de>,
	Vojtěch Pavlík <vojtech@...e.com>,
	Gary Ching-Pang Lin <glin@...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 Thu, Aug 27, 2015 at 3:36 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> On Wed, Aug 26, 2015 at 10:35:19PM -0400, Paul Moore wrote:
>> On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
>> > On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
>> > Now let's review the SELinux stuff before we jump back into firmware / system
>> > data stuff again as there is a joint criteria to consider for all of these.
>> > For other people's refrence the enum you quote above was added through your
>> > patch pending on linux-next:
>> >
>> > "PKCS#7: Appropriately restrict authenticated attributes and content type"
>> >
>> > Based on what Roberts seems to want to do for SELinux policy files it would
>> > seems we may also need VERIFYING_SELINUX_POLICY. SELinux policy loading is
>> > unique in the at it uses its own fs and uses a load trigger node (sel_load_ops)
>> > to kick off  security_load_policy(data, count), so its not exactly a
>> > yet-another-API to read arbitrary files from the file system. Its policy files
>> > are also very distribution specific. Because of all this its not really
>> > suitable for /lib/firmware/ or sharing code even futher. It seems its a prime
>> > candidate already to make use of the system_verify_data() APIs you added David,
>> > provided the items below are taken care of as well.
>>
>> One thing to keep in mind is that not only are SELinux policy files
>> distribution specific, they are machine specific as administrators
>> can, and do, customize the policy for their usage.  I really like the
>> idea of providing signed SELinux policies to the kernel but I question
>> how practical it will be for normal users/admins.
>
> Yeah that makes it harder. Possible but harder.
>
>> Some of the Machine Owner Key (MOK) work would likely be necessary for
>> signed SELinux policies to be even remotely practical.
>
> Matthew, Peter and Gary are Cc'd, so they can feel free to chime in.
>
> There are other alternatives as well:
>
>  * Is there wide use of SELinux + IMA ? If so that may be another option.

I'm not aware of any large scale use of SELinux+IMA, although it is
doubtful that IMA will be of use for protecting the SELinux policy
since it is written into the kernel, the kernel doesn't load it
directly.  There is also the issue that the SELinux userspace tends to
manipulate the policy such that the blob that is written into the
kernel isn't the same blob that is read from disk.

I imagine one could use IMA to protect the SELinux policy store, but
that isn't the same as protecting the binary security policy that is
written to the kernel.

-- 
paul moore
www.paul-moore.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/