From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965409AbcALPSM (ORCPT ); Tue, 12 Jan 2016 10:18:12 -0500 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:41376 "EHLO e23smtp07.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965237AbcALPSK (ORCPT ); Tue, 12 Jan 2016 10:18:10 -0500 X-IBM-Helo: d23dlp03.au.ibm.com X-IBM-MailFrom: zohar@linux.vnet.ibm.com X-IBM-RcptTo: keyrings@vger.kernel.org;linux-kernel@vger.kernel.org;linux-security-module@vger.kernel.org Message-ID: <1452611828.4776.181.camel@linux.vnet.ibm.com> Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring From: Mimi Zohar To: David Howells Cc: "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 Date: Tue, 12 Jan 2016 10:17:08 -0500 In-Reply-To: <14160.1452606924@warthog.procyon.org.uk> 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> <14160.1452606924@warthog.procyon.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16011215-0025-0000-0000-000002BC7496 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-01-12 at 13:55 +0000, David Howells wrote: > 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. It becomes a problem if the existing system keyring semantics of not being writable change or if non builtin keys are added to the system keyring. Discussion continued below. > 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. There are two main concerns: - Different keys are trusted for different things (eg. firmware, modules, regular files) and at different levels of the OS. I guess this could be addressed, as you've previously suggested, by identifiers. - The other issue is transitive trust (eg. A trusts B. B trusts C. Permit anything signed by C). In some use case scenarios this is desired, in others it is not. We would need the option to limit trust to just the builtin keys to support both use cases. Even with the identifier support and ability to limit transitive trust, I doubt it is as safe as limiting the system keyring to just the builtin keys. Refer to Petko's post. > > 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()? Good. restrict_link_by_ima_trusted would only check the IMA MOK keyring if it was configured. Mimi