From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757499AbcAJUdo (ORCPT ); Sun, 10 Jan 2016 15:33:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36642 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757266AbcAJUdm (ORCPT ); Sun, 10 Jan 2016 15:33:42 -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: <2033.1452447990@warthog.procyon.org.uk> References: <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> To: Mimi Zohar , James Morris Cc: dhowells@redhat.com, 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: <3383.1452458018.1@warthog.procyon.org.uk> Date: Sun, 10 Jan 2016 20:33:38 +0000 Message-ID: <3384.1452458018@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Howells wrote: > Mimi Zohar wrote: > > > > Is this a NAK on the patch? > > > > Yes > > I would like to counter Mimi's NAK: > > (1) Commit 41c89b64d7184a780f12f2cccdabe65cb2408893 doesn't do what it > says. Given the change I want to revert, this bit of the description: > > To successfully import a key into .ima_mok it must be signed by a > key which CA is in .system keyring. > > is *not* true. A key in the .ima_mok keyring will *also* allow a key > into the .ima_mok keyring. Thus the .ima_mok keyring is redundant and > should be merged into the .system keyring. > > (2) You can use KEYCTL_LINK to link trusted keys between trusted keyrings > if the key being linked grants permission. Add a new key to one open > keyring and you can then link it across to another. > > Keyrings need to guard against *link* as per my recently posted > patches. > > (3) In the current model, the trusted-only keyring and trusted-key concept > ought really to apply only to the .system keyring as the concept of > 'trust' is boolean in this implementation. > > Again, I want to change this as per my recently posted patches. (4) Marcel asked to have user-based 'trusted' keyrings - where userspace can load a keyring up and then mark it as 'trusted' thereby limiting further additions - for the use with kernel-based TLS. These would *not* depend on the .system keyring. Unless we're willing to store the root CA certificate for the world in the kernel, we can't really do that. David