From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760308AbcALDhF (ORCPT ); Mon, 11 Jan 2016 22:37:05 -0500 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:59696 "EHLO e23smtp08.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759732AbcALDhC (ORCPT ); Mon, 11 Jan 2016 22:37:02 -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: <1452569755.4776.69.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: Mon, 11 Jan 2016 22:35:55 -0500 In-Reply-To: <31702.1452564218@warthog.procyon.org.uk> References: <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> 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: 16011203-0029-0000-0000-000002C29039 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-01-12 at 02:03 +0000, David Howells wrote: > See the patch ensubjected: > > [RFC PATCH 14/15] KEYS: Move the point of trust determination to __key_link() > > Search for keyring_alloc and particularly restrict_link_by_ima_mok. > > The restriction function cannot currently be cleared or modified by userspace > - though I have an idea to make it possible to *impose* a restriction through > keyctl() on any keyring that doesn't yet have a restriction imposed. > > The restriction function can impose any restrictions it likes, using the key's > parsed payload, key type, the current keyring contents and any other keyring > contents as it wishes in evaluating the trustworthiness of a key. One assumption is that ima-mok is always enabled, which isn't true and not the default. Depending on whether it is enabled, the ima keyring would need to be restricted by "restrict_link_by_ima_mok" or "restrict_link_by_system_trusted". The IMA MOK and blacklist are restricted to "public_key_restrict_link". Does this only allow keys signed by keys on the respective keyring or also by the system keyring? As long as the system keyring is limited to just the builtin keys, then this looks promising. Otherwise, perhaps a separate "builtin" keyring should be defined. Mimi