linux-kernel - Re: [RFC 2/2] initramfs with digital signature protection

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] [day] [month] [year] [list]

Date:	Fri, 12 Apr 2013 07:54:29 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Josh Boyer <jwboyer@...il.com>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/2] initramfs with digital signature protection

On Thu, 2013-04-11 at 10:52 -0400, Vivek Goyal wrote:
> On Wed, Apr 10, 2013 at 05:05:22PM -0400, Mimi Zohar wrote:
> > On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
> > > On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
> > > 
> > > [..]
> > > > The module keyring is a special case.  Loading these keys from the
> > > > kernel and, presumably, locking the keyring is probably fine.  In the
> > > > case of IMA, however, files will be signed by any number of package
> > > > owners.  If the _ima keyring is locked by the kernel, how would you add
> > > > these other keys?
> > > 
> > > Who are package owners here. IOW, in typical IMA setup, where are the keys
> > > and when are these keys loaded in ima keyring?
> > 
> > Suppose I install third party packages not signed by the distro, but by
> > the package owner (eg. google, rpmfusion, ...).  Not only does the
> > package signature need to be verified on installation, but the files
> > need to be installed with signatures.  For IMA to enforce file
> > integrity, the package owner's public key needs to be added to the _ima
> > keyring.
> 
> Ok, got it. 
> 
> > 
> > > If we trust root and keys can be loaded any time later, then signed
> > > initramfs will not solve the problem either.
> > 
> > Locking the keyring in the kernel will limit the set of permitted keys
> > to only those specified in UEFI db or builtin.  Locking the keyring in
> > the "early" initramfs, will allow the system owner, whose key is in the
> > UEFI db, to specify additional keys, such as those for third party
> > packages.  Not all public keys belong in the UEFI db.
> 
> Ok, so third party public key you don't want to add in UEFI db. Instead
> platform owner (whose key is in UEFI db) will regenerate initrafs and
> sign it.
> 
> So above use case is primarily for user space files and verifying its
> integrity and IMA keyring is used for that. secureboot does not require
> IMA keyring to be locked as none of that code runs at ring0.
> 
> This locking requirement of IMA keyring is coming in only because we are
> trying to also verify the integrity of a process who will load code which
> runs at ring0.
> 
> So how do you like the idea of using another keyring (say system keyring)
> for this purpose and what keyring to use integrity of a file can be
> encoded in file signature.
> 
> This is something similar to INTEGRITY_KEYRING_MODULE keyring for modules.
> (Though I don't see this code fully hooked up yet).
> 
> Or, given the fact that module signature and here /sbin/kexec verification
> will make use of similar keys, we can create a system keyring, make module
> code make use of that keyring. And IMA code can make use of that keyring
> too if a file's digital signature indicates so.

Sounds good to me!

thanks,

Mimi

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