Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932908AbcCHQiR (ORCPT ); Tue, 8 Mar 2016 11:38:17 -0500 Received: from lan.nucleusys.com ([92.247.61.126]:35430 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932275AbcCHQiG (ORCPT ); Tue, 8 Mar 2016 11:38:06 -0500 Date: Tue, 8 Mar 2016 18:37:58 +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: <20160308163758.GA4934@localhost> Mail-Followup-To: David Howells , Mimi Zohar , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org 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> <3362.1457453220@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3362.1457453220@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 16:07:00, David Howells wrote: > 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. [...] 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: 1906 Lines: 45 On 16-03-08 16:07:00, David Howells wrote: > 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. Exactly. The primary difference between the built-in and secondary keyring is that the latter is R/W. Chances are the user want either no addition or need dynamic key add/remove. I don't have strong opinions against (2). This is more of a discussion whether we should sacrifice in favor of simplicity or flexibility. > Remember - these keyrings aren't necessarily restricted to IMA. I am well aware of that. At some point (perhaps not now) i'd like to discuss allowing kernel module loading based on keys in the secondary keyring. It is a niche feature for those machines that have uptime measured in years. I certainly don't expect it to be something the regular desktop or embedded users need. Another issue that we left unresolved is the system-wide blacklist keyring. It is at the same hierarchy level as the secondary keyring and serves a similar purpose although in opposite direction. Petko