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]

Message-id: <52724BAC.1080902@samsung.com>
Date:	Thu, 31 Oct 2013 14:23:08 +0200
From:	Dmitry Kasatkin <d.kasatkin@...sung.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.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 31/10/13 14:03, Mimi Zohar wrote:
> 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.

Then all keys on that keyring must be signed..
This is not what I was saying...

It is always possible to specify keyring hierarchy and rules what
verifies what.
But may be better not to over-engineer...

It is how it is now.. Will see based on use-cases in the future...

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

In prototype implementation I used kernel module verification
function... module key...

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

You need to embed local-ca somehow into the kernel..
Or pass/read and verify it somehow...

- Dmitry

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