Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754005AbcCHOOj (ORCPT ); Tue, 8 Mar 2016 09:14:39 -0500 Received: from lan.nucleusys.com ([92.247.61.126]:35344 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751632AbcCHOOa (ORCPT ); Tue, 8 Mar 2016 09:14:30 -0500 X-Greylist: delayed 481 seconds by postgrey-1.27 at vger.kernel.org; Tue, 08 Mar 2016 09:14:29 EST Date: Tue, 8 Mar 2016 16:14:29 +0200 From: Petko Manolov To: David Howells Cc: 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] Message-ID: <20160308141429.GC2243@p310> Mail-Followup-To: David Howells , Mimi Zohar , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30481.1457442516@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-03-08 13:08:36, David Howells wrote: > Mimi Zohar wrote: > > > Only certificates signed by a key on the system keyring were added to > > the IMA keyring, unless IMA_MOK_KEYRING was configured. Then, the > > certificate could be signed by a either a key on the system or ima_mok > > keyrings. To replicate this behavior, the default behavior should be to > > only permit certificates signed by a key on the builtin keyring, unless > > this new Kconfig is enabled. Only then, permit certificates signed by a > > key on either the builtin or secondary keyrings to be added to the IMA > > keyring. > > 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. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1238 Lines: 31 On 16-03-08 13:08:36, David Howells wrote: > Mimi Zohar wrote: > > > Only certificates signed by a key on the system keyring were added to > > the IMA keyring, unless IMA_MOK_KEYRING was configured. Then, the > > certificate could be signed by a either a key on the system or ima_mok > > keyrings. To replicate this behavior, the default behavior should be to > > only permit certificates signed by a key on the builtin keyring, unless > > this new Kconfig is enabled. Only then, permit certificates signed by a > > key on either the builtin or secondary keyrings to be added to the IMA > > keyring. > > 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. cheers, Petko