From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965431AbcALNzb (ORCPT ); Tue, 12 Jan 2016 08:55:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48569 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965393AbcALNz3 (ORCPT ); Tue, 12 Jan 2016 08:55:29 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1452604893.4776.134.camel@linux.vnet.ibm.com> References: <1452604893.4776.134.camel@linux.vnet.ibm.com> <1452569755.4776.69.camel@linux.vnet.ibm.com> <88773.1452562139@eng-mail01.juniper.net> <1452470153.2651.60.camel@linux.vnet.ibm.com> <2033.1452447990@warthog.procyon.org.uk> <1452432410.2651.40.camel@linux.vnet.ibm.com> <20160106134525.15633.73582.stgit@warthog.procyon.org.uk> <24185.1452126854@warthog.procyon.org.uk> <1452180676.2890.21.camel@linux.vnet.ibm.com> <3384.1452458018@warthog.procyon.org.uk> <27007.1452559481@warthog.procyon.org.uk> <31702.1452564218@warthog.procyon.org.uk> <31422.1452593319@warthog.procyon.org.uk> To: Mimi Zohar Cc: dhowells@redhat.com, "Mark D. Baushke" , James Morris , Marcel Holtmann , petkan@mip-labs.com, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14159.1452606924.1@warthog.procyon.org.uk> Date: Tue, 12 Jan 2016 13:55:24 +0000 Message-ID: <14160.1452606924@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mimi Zohar 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