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]
Date:	Mon, 8 Apr 2013 16:09:04 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	"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 Mon, Apr 08, 2013 at 03:43:49PM -0400, Mimi Zohar wrote:
> On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
> > On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
> > 
> > [..]
> > > > Also I am assuming that from signed initramfs, keys will be loaded in
> > > > appropriate keyrings and then keyring will be locked so that any
> > > > tools from unsigned initramfs can not load additional keys.
> > > >
> > > 
> > > Exactly like that.
> > 
> > Dmitry,
> > 
> > [ Following up on this thread after a very long time ]
> > 
> > I was thinking about this point that keys can be loaded from signed
> > initramfs. But how is it better than embedding the keys in kernel the
> > way we do for module signing and lock down ima keyring before control
> > is passed to initramfs.
> > 
> > Reason being, that anyway a user can not put its own keys in signed
> > initramfs. Signed initramfs will be shipped by distribution. So then
> > it does not matter whether distribution's keys are embedded in the
> > kernel or are loaded from signed initramfs.
> 
> Although both the early initramfs and the kernel are signed, building
> the keys into the kernel implies a static set of predefined public keys,
> while the initramfs could load, in addition to the distro keys, keys
> from the UEFI databases.

Kernel already loads all the keys from UEFI database and MOK into module
keyring.

So that can be true for IMA too. A user can add its keys to UEFI database
or MOK and reboot the system and those keys should show up in kernel
keyring.

In addition any keys embedded in kernel at build time will be loaded too.

>  (Refer to James Bottomley's post on efivarfs.)

Are you referring to following link.

http://blog.hansenpartnership.com/efitools-1-4-with-linux-key-manipulation-utilities-released/

This one seems to be talking about tools for adding your own keys to
UEFI database if one has PK and KEK.

> If distro's would sign such an early initramfs, it would allow users to
> add their own keys in a safe and secure manner, without requiring them
> to rebuild the kernel.
> 

Sorry, I did not understand this part. Even if user adds its own keys
in UEFI database (using efivarfs filesystem), it does not require
rebuiling kernel. Over next reboot these keys should show up in kernel
keyring. So does not look like we will gain anything by creating a signed
initramfs.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ