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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20130410194209.GF6602@redhat.com>
Date:	Wed, 10 Apr 2013 15:42:09 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.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 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?

If we trust root and keys can be loaded any time later, then signed
initramfs will not solve the problem either.

So this boils down to again not trusting root. So secureboot will not
trust root and IMA does. 

May be we need an additional IMA keyring which gets locked by kernel
(like module keyring). And during signing, we need to encode keyring
info in file signatuer. IMA will parse keyring info and try to verify
signature against that specified keyring.

/sbin/kexec signing can happen in such a way that we tell IMA to verify
against this locked keyring say, ima_kernel.

And in regular ima keyring, root can continue to load its own keys in
usual way even in secureboot mode.

Just that sys_kexec() will have to call into IMA to make sure that
/sbin/kexec's integrity was verified using keys in ima_kernel keyring 
and not using keys in _ima keyring.

IOW, apart from integrity results, we will have to store the keyring
info too in results which should be queryable by the client. And then
client can decide how to interpret integrity results.

Or we can just export the APIs from IMA (which don't do any caching) and
client can specify keyring to verify against as a parameter.

Thoughts?

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/