From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757330AbcAJRqe (ORCPT ); Sun, 10 Jan 2016 12:46:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59666 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757267AbcAJRqd (ORCPT ); Sun, 10 Jan 2016 12:46:33 -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: <1452432410.2651.40.camel@linux.vnet.ibm.com> References: <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, 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: <2032.1452447990.1@warthog.procyon.org.uk> Date: Sun, 10 Jan 2016 17:46:30 +0000 Message-ID: <2033.1452447990@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. David