linux-kernel - Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key

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: <20140612172320.GJ9578@redhat.com>
Date:	Thu, 12 Jun 2014 13:23:20 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	Dmitry Kasatkin <d.kasatkin@...sung.com>, dhowells@...hat.com,
	jwboyer@...hat.com, keyrings@...ux-nfs.org,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"dmitry.kasatFionnuala Gunter" <fin@...ux.vnet.ibm.com>,
	kin@...il.com, mjg59@...f.ucam.org
Subject: Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key

On Thu, Jun 12, 2014 at 01:17:03PM -0400, Mimi Zohar wrote:
> On Thu, 2014-06-12 at 13:00 -0400, Vivek Goyal wrote: 
> > On Thu, Jun 12, 2014 at 12:55:26PM -0400, Mimi Zohar wrote:
> > > On Thu, 2014-06-12 at 12:03 -0400, Vivek Goyal wrote: 
> > > > On Tue, Jun 10, 2014 at 11:48:17AM +0300, Dmitry Kasatkin wrote:
> > > > > This patch provides kernel parameter to specify owner's key id which
> > > > > must be used for trust validate of keys. Keys signed with other keys
> > > > > are not trusted.
> > > > > 
> > > > > Signed-off-by: Dmitry Kasatkin <d.kasatkin@...sung.com>
> > > > 
> > > > Hi,
> > > > 
> > > > I am continuing to work on verifying kernel signature for kexec/kdump. I 
> > > > am planning to take david howell's patches for pkcs7 signature
> > > > verification and verify bzImage signature.
> > > > 
> > > > Part of that process will boil down to verifying a certificate in
> > > > pkcs7 x509 cert chain using a key in system_trusted_keyring.
> > > > 
> > > > I think the OS vendor key which signs the kernel signing key propagates to
> > > > system_trusted_keyring. (shim has that and I am not sure how shim makes
> > > > it propogate all they way to system_trusted_keyring).
> > > 
> > > The shim patches are here
> > > http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
> > > 
> > > > So I was planning to use same functionality where I look for any key
> > > > which can verify the signing cert of kernel. As OS vendor key will be
> > > > in system_trusted_keyring, it should work.
> > > > 
> > > > Now with this change where you will trust only one selected owner key.
> > > > That means you will not even trust the OS vendor key which signs kernel
> > > > signing key. I think this will stop working with  keys_ownerid=<....>
> > > > 
> > > > As I am doing that work in parallel and I saw these patches, I thought
> > > > I will bring it up.
> > > 
> > > Right, the current discussion is whether we need an owner trusted
> > > keyring or if just one key was enough.  Thanks for chiming in.
> > > 
> > > The other option would be to sign the bzImage file creating a
> > > 'security.ima' extended attribute and verifying it.  Have you created a
> > > security kexec hook?
> > 
> > No, I have not created another hook. As bzImage is already signed it is
> > much simpler to verify same signature instead of carrying another set
> > of detached signatures and key management etc.
> 
> Fin (cc'ed) has patches that include the file signatures in the RPM
> header and installs them.  There wouldn't be any need for a separate
> detached signature.

Currently distributions are already shipping bzImage signed with PE/COFF
signature. If we go this way, now they will have to sign bzImage twice.
And this time in IMA format and pack signatures in rpm. Managing two
different signatures for same bzImage is just going to be an unnecessary
headache for everybody, IMHO.

I am wondering how about coming up with x509_validate_trust_key() where
you specify that validate trust against a specific key (instead of
keyring). Another function will be x509_validate_trust() which will take
keyring as input and will trust all keys in keyring.

As I am not adding a key, I can just use x509_validate_trust(system_keyring)
for signature verification and in key add path you can continue to
use x509_validate_trust_key() if somebody used command line keys_ownerid=.

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/