From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757687AbcAJX4H (ORCPT <rfc822;w@1wt.eu>);
	Sun, 10 Jan 2016 18:56:07 -0500
Received: from e28smtp06.in.ibm.com ([125.16.236.6]:35907 "EHLO
	e28smtp06.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757233AbcAJX4E (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 10 Jan 2016 18:56:04 -0500
X-IBM-Helo: d28dlp01.in.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: <1452470153.2651.60.camel@linux.vnet.ibm.com>
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against
 IMA MOK keyring
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>, Marcel Holtmann <marcel@holtmann.org>,
        petkan@mip-labs.com, linux-security-module@vger.kernel.org,
        keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Date: Sun, 10 Jan 2016 18:55:53 -0500
In-Reply-To: <3384.1452458018@warthog.procyon.org.uk>
References: <2033.1452447990@warthog.procyon.org.uk>
	 <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>
	 <alpine.LRH.2.20.1601102135470.6161@namei.org>
	 <3384.1452458018@warthog.procyon.org.uk>
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: 16011023-0021-0000-0000-00000973C532
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, 2016-01-10 at 20:33 +0000, David Howells wrote:
> David Howells <dhowells@redhat.com> wrote:

>  (4) Marcel asked to have user-based 'trusted' keyrings - where userspace
>      can load a keyring up and then mark it as 'trusted' thereby limiting
>      further additions - for the use with kernel-based TLS.
> 
>      These would *not* depend on the .system keyring.  Unless we're willing
>      to store the root CA certificate for the world in the kernel, we can't
>      really do that.

Is this the primary use case scenario for your patches?   Unfortunately,
your posted patches would break the existing IMA trust model.   Let's
identify the different use case scenarios and work together to meet the
different requirements.

Mimi