Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932682AbcCHQHJ (ORCPT ); Tue, 8 Mar 2016 11:07:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34239 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752904AbcCHQHD convert rfc822-to-8bit (ORCPT ); Tue, 8 Mar 2016 11:07:03 -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: <20160308141429.GC2243@p310> References: <20160308141429.GC2243@p310> <1457403993.5321.33.camel@linux.vnet.ibm.com> <20160304150022.17121.34501.stgit@warthog.procyon.org.uk> <20160304150149.17121.31855.stgit@warthog.procyon.org.uk> <30481.1457442516@warthog.procyon.org.uk> To: Petko Manolov Cc: dhowells@redhat.com, Mimi Zohar , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3361.1457453220.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Tue, 08 Mar 2016 16:07:00 +0000 Message-ID: <3362.1457453220@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 965 Lines: 26 Petko Manolov wrote: > > How about I change it to a choice-type item, with the following options: > > > > (1) No addition. > > > > (2) Addition restricted by built-in keyring. > > > > (3) Addition restricted by secondary keyring + built-in keyring. > > > > where the second and third options then depend on the appropriate keyrings > > being enabled. > > I would suggest leaving (1) and (3). Since secondary keyring only accepts > keys signed by certificate in the system keyring I think (2) is redundant. > It adds extra complexity (Kconfig is vague enough already) while it doesn't > increase the overall security by much. If I remove option (2), that would mean that if you want to allow keys to be added to .ima if they're signed by the built-in keyring, then you also allow keys to be added to .ima if they're signed by the secondary keyring if enabled. Remember - these keyrings aren't necessarily restricted to IMA. David