linux-kernel - Re: [PATCH] ima: define '_ima' as a builtin 'trusted' keyring

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]

Date:	Thu, 31 Oct 2013 08:03:27 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Dmitry Kasatkin <d.kasatkin@...sung.com>
Cc:	linux-security-module <linux-security-module@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ima: define '_ima' as a builtin 'trusted' keyring

On Thu, 2013-10-31 at 10:30 +0200, Dmitry Kasatkin wrote:
> On 30/10/13 20:54, Mimi Zohar wrote:
> > Require all keys added to the IMA keyring be signed by an
> > existing trusted key on the system trusted keyring.
> >
> > Changelog:
> > - define stub integrity_init_keyring() function (reported-by Fengguang Wu)
> > - differentiate between regular and trusted keyring names.
> > - replace printk with pr_info (D. Kasatkin)
> >
> > Signed-off-by: Mimi Zohar <zohar@...ibm.com>
> > ---
> >  security/integrity/digsig.c           | 30 +++++++++++++++++++++++++++++-
> >  security/integrity/ima/Kconfig        |  8 ++++++++
> >  security/integrity/ima/ima_appraise.c | 11 +++++++++++
> >  security/integrity/integrity.h        |  7 +++++++
> >  4 files changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> > index b4af4eb..77ca965 100644
> > --- a/security/integrity/digsig.c
> > +++ b/security/integrity/digsig.c
> > @@ -13,7 +13,9 @@
> >  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >  
> >  #include <linux/err.h>
> > +#include <linux/sched.h>
> >  #include <linux/rbtree.h>
> > +#include <linux/cred.h>
> >  #include <linux/key-type.h>
> >  #include <linux/digsig.h>
> >  
> > @@ -21,11 +23,19 @@
> >  
> >  static struct key *keyring[INTEGRITY_KEYRING_MAX];
> >  
> > +#ifdef CONFIG_IMA_TRUSTED_KEYRING
> > +static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
> > +	".evm",
> > +	".module",
> > +	".ima",
> > +};
> > +#else
> >  static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
> >  	"_evm",
> >  	"_module",
> >  	"_ima",
> >  };
> > +#endif
> 
> Hello,
> 
> I am not sure if having 2 different names "_" and "." makes sense.

The existing keyring implementation permits userspace to create a new
keyring with the exact same name as a previously defined trusted
keyring.  For all practical purposes, replacing a trusted keyring with
an untrusted one.  The existing solution is to prohibit userspace from
creating a dot prefixed keyring.  

Allowing only signed keys to be added to the IMA keyring breaks the
existing userspace/kernel ABI, which has existed since linux-3.3.  At
some point, we could deprecate the non trusted keyring. 

> Setting trusted-only makes sense until we will get support of setting
> trusted only from user-space using keyctl...

Agreed, userspace should be permitted to create a trusted keyring, but
not change an existing keyring to trusted.

> David, do you remember our discussion in Edinburgh?
> Can you provide a way to set keyring as trusted-only from user space..
> 
> Motivation...
> 
> In many embedded systems, initramfs is built into the kernel image.
> Kernel image is signed and obviously initramfs as well..
> Or initramfs may be signed separately like in my prototype implementation...

> Note that non-x86 systems - embedded, mobile, etc has no UEFI, MOK.
> Initial keys cannot be verified. (we should not rely on using kernel
> modules key)
> Thus keys on the protected initramfs may not be required to be signed..

In the builtin initramfs case, the public key is included in the signed
image.  Where is the key stored that verifies the separately signed
initramfs?  Is there a signature chain of trust?

If there is a signature chain of trust and a local-ca signed the
initramfs, then the local-ca key could be added to the system keyring
and used to sign keys for the IMA keyring.

thanks,

Mimi

> It must be a way to add "initial keys" from user-space...
> This is like "setting initial trust"..
> This kind of functionality also useful for ".system" keyring itself.

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