From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756478AbcAHTVY (ORCPT ); Fri, 8 Jan 2016 14:21:24 -0500 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:46143 "EHLO e23smtp06.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754376AbcAHTVW (ORCPT ); Fri, 8 Jan 2016 14:21:22 -0500 X-IBM-Helo: d23dlp02.au.ibm.com X-IBM-MailFrom: zohar@linux.vnet.ibm.com X-IBM-RcptTo: keyrings@vger.kernel.org;linux-kernel@vger.kernel.org;linux-security-module@vger.kernel.org Message-ID: <1452280713.2651.12.camel@linux.vnet.ibm.com> Subject: Re: [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings From: Mimi Zohar To: David Howells Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, petkan@mip-labs.com, linux-kernel@vger.kernel.org Date: Fri, 08 Jan 2016 14:18:33 -0500 In-Reply-To: <1452279264.2651.7.camel@linux.vnet.ibm.com> References: <20160108183319.25960.49807.stgit@warthog.procyon.org.uk> <1452279264.2651.7.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16010819-0021-0000-0000-00000278B18E Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-01-08 at 13:54 -0500, Mimi Zohar wrote: > On Fri, 2016-01-08 at 18:33 +0000, David Howells wrote: > > Here's a set of patches that changes how keys are determined to be trusted > > - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon > > it. A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that > > indicates that only keys with this flag set may be added to that keyring. > > > > Further, any time an X.509 certificate is instantiated without this flag > > set, the certificate is judged against the contents of the system trusted > > keyring to determine whether KEY_FLAG_TRUSTED should be set upon it. > > > > With these patches, KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed. > > > > The kernel may add implicitly trusted keys to a trusted-only keyring by > > asserting KEY_ALLOC_BYPASS_RESTRICTION when the key is created, but > > otherwise the key will only be allowed to be added to the keyring if it can > > be verified. The system trusted keyring is not then special in this sense > > and other trusted keyrings can be set up that are wholly independent of it. > > In order to have a certificate chain of trust on any of these trusted > keyrings, the system keyring needs to be special. Even if we permit > transitive trust, meaning keys on a keyring can be used to validate > other keys being added to the same keyring, the first key added to a > trusted keyring needs to be vetted against something. That something > needs to be the builtin keys on the system keyring. Back in November, Mehmet Kayaalp posted a patch for safely adding additional keys to the system keyring post build and a tool for re-signing the kernel. https://www.mail-archive.com/linux-security-module@vger.kernel.org/msg03679.html Mimi