linux-kernel - Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160112141150.GA4806@bender.nucleusys.com>
Date:	Tue, 12 Jan 2016 16:11:50 +0200
From:	Petko Manolov <petkan@...-labs.com>
To:	David Howells <dhowells@...hat.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	"Mark D. Baushke" <mdb@...iper.net>,
	James Morris <jmorris@...ei.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against
 IMA MOK keyring

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