linux-kernel - Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK 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:	Tue, 12 Jan 2016 13:55:24 +0000
From:	David Howells <dhowells@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	dhowells@...hat.com, "Mark D. Baushke" <mdb@...iper.net>,
	James Morris <jmorris@...ei.org>,
	Marcel Holtmann <marcel@...tmann.org>, petkan@...-labs.com,
	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring

Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:

> >  (1) public_key_restrict_link() restricts to asymmetric keys that are
> >      signed by a CA in the specified keyring.  It returns -ENOKEY if no
> >      matching key is found rather than -EKEYREJECTED, however, so you can
> >      call it several times for different keyrings.  -EKEYREJECTED is only
> >      returned if a signature check fails.  This is used by the following
> >      two functions.
> 
> Ok, so it is restricted it to CAs.  Combining it with an option to limit
> it to the builtin CA keys based on the builtin flag would be nice.

Is there a point to the builtin flag if .system_keyring is closed?  Currently
all keys that go into .system_keyring are marked BUILTIN.

But, yes, the restriction can include only using built in CAs.

> >  (1) .system_keyring uses restrict_link_by_system_trusted() - though it
> >      lacks any sort of write permission, so it's currently moot.  It could
> >      just as well be replaced with a function that just returns -EPERM.
> 
> Why not retain the current semantics of the system keyring of not being
> writable and create a new keyring for new feature(s)?

I think that the problem we have is that it can be argued either way.  You
would rather create a new keyring to hold additional keys, whereas I would
prefer to use the keyring we already have.

Do you have a technical reason why we can't just open the system keyring?
It's not precisely a new feature, but rather an extension to an existing one
that's been under consideration for a while.

> The name "restrict_link_by_ima_mok()" doesn't reflect that it is either
> the system keyring or the IMA MOK keyring.

How about restrict_link_by_ima_trusted()?

David