From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757506AbcAJUdx (ORCPT ); Sun, 10 Jan 2016 15:33:53 -0500 Received: from lan.nucleusys.com ([92.247.61.126]:54784 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757266AbcAJUdt (ORCPT ); Sun, 10 Jan 2016 15:33:49 -0500 Date: Sun, 10 Jan 2016 22:33:39 +0200 From: Petko Manolov To: David Howells Cc: Mimi Zohar , James Morris , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, mdb@juniper.net Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring Message-ID: <20160110203339.GE10864@localhost> Mail-Followup-To: David Howells , Mimi Zohar , James Morris , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, mdb@juniper.net 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> <2033.1452447990@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2033.1452447990@warthog.procyon.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "zztop.nucleusys.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 16-01-10 17:46:30, 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 [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16-01-10 17:46:30, 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 This is correct, but is also the desired result. Assume that you have multi tenant machine where the manufacturer signs the owner's/tenant's key and those also need to sign other sub-tenant keys. One can't put them on the system keyring so they end up in .ima_mok. > into the .ima_mok keyring. Thus the .ima_mok keyring is redundant and > should be merged into the .system keyring. I share Mimi's opinion that .system keyring must be static and ultimately trusted. Since .ima_mok is a dynamic keyring, merging them will break the semantics. > (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. I'd rather rely on a certificate being properly signed in order to land in a particular keyring, rather than being linked based on permissions model. > (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. The .system keyring should be read-only, IOW static. Only keys present at build time should go there. Everything else goes to the machine owner keyring (MOK) or whatever the name. MOK should be read-write and (maybe) hold only second level CAs, signed by CA in the system keyring. I introduced .ima_mok just because my work had limited scope at the time and i consider the name as misleading. The way i see kernel's keyrings: /---> .ima /----> MOK ---< .system ---< \---> .evm \----> BL \---> .whatever need to be "trusted" The graph could be a lot more complex, but to wrap your head around the idea think of big ass machine with years of uptime and multiple simultaneous users, all pre-installed files IMA signed, ability to add other IMA signed packages on the fly. The machine must be FIPS certifiable, etc. A terabit switching machine should be able to do that and there are real users for this scenario out there. The black-list keyring is equally important so one can revoke CAs if need be. On the fly. Petko