lkml.org 
[lkml]   [2016]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2016-01-12 15:41    [W:0.058 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site