From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934664AbcALONa (ORCPT ); Tue, 12 Jan 2016 09:13:30 -0500 Received: from lan.nucleusys.com ([92.247.61.126]:55128 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934483AbcALOMW (ORCPT ); Tue, 12 Jan 2016 09:12:22 -0500 Date: Tue, 12 Jan 2016 16:11:50 +0200 From: Petko Manolov To: David Howells Cc: Mimi Zohar , "Mark D. Baushke" , James Morris , Marcel Holtmann , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring Message-ID: <20160112141150.GA4806@bender.nucleusys.com> Mail-Followup-To: David Howells , Mimi Zohar , "Mark D. Baushke" , James Morris , Marcel Holtmann , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org 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> <3384.1452458018@warthog.procyon.org.uk> <27007.1452559481@warthog.procyon.org.uk> <31702.1452564218@warthog.procyon.org.uk> <31422.1452593319@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31422.1452593319@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: Guys, i'd like to take a step back, make a short keyring overview (the way i see it) and see if we're all on the same page. Implementation details matters, but only if we've agreed on the architecture first. This is how i see the _trusted_ keyrings hierarchy in the kernel. I don't claim i am right... :) [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Guys, i'd like to take a step back, make a short keyring overview (the way i see it) and see if we're all on the same page. Implementation details matters, but only if we've agreed on the architecture first. This is how i see the _trusted_ keyrings hierarchy in the kernel. I don't claim i am right... :) (1) I really think the system keyring should remain static. The only time you can really trust your kernel is at it's build time. Later on, when it is running, it may fail you in a great many and spectacular ways, thanks to the bugs we all introduce. Unless the kernel is terribly broken the system keyring should not contain anything else but the built-in certificates. This will serve as foothold of sanity in an extremely dynamic and sometimes quite messy world. Most production grade kernels are built in a clean room environment with restricted physical access. You can't get as good level of security once they are released in the wild. (2) IMA MOK and blacklist keyrings - right now they are implemented as an aid to the IMA subsystem, but really should be system-wide keyrings. Assuming the .system is read-only the only way you can dynamically add _trusted_ certificates to your kernel is via some sort of read-write keyring that is _dependent_ on the .system. MOK (or, again, whatever the name) should be the second level of _trusted_ keyrings. .ima and .evm are the obvious users, but there may be others in the future and represents the leafs of the trusted keyring graph. (3) the blacklist keyring - it is at the same hierarchy level as the system keyring, but for obvious reasons, can't be read-only. Since it should be the first keyring we check we can't allow stuff to go there randomly. One thing i can think of is the standard CA signature verification. Only keys that are properly signed should go there. This check should not be enough to guarantee entry in .blacklist otherwise it will be very easy to DoS IMA-appraisal enabled system. Additional criteria should be introduced when moving keys to this keyring. I would like to once again state that .ima_mok and .ima_blacklist should really be system wide keyrings. It so happened that i worked with Mimi Zohar and Mark Baushke and my focus was the IMA/EVM subsystem. I (maybe naively) thought IMA would serve as a test ground for the concept and once it mature it may move up. It now seems that we need to agree on an architecture that will serve all newly introduced use-cases. Petko