[Ksummit-discuss] Last minute nominations: mcgrof and toshi
James Bottomley
James.Bottomley at HansenPartnership.com
Wed Jul 27 15:06:27 UTC 2016
On Tue, 2016-07-26 at 15:42 +0100, David Woodhouse wrote:
> On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> >
> > > Oops, "Signature management - keys, modules, firmware" was a
> > > suggestion
> > > from last year, but in my opinion still very apropos.
> >
> > Yup, definitely - especially with secure boot starting to firm up
> > on the ARM side there's a bunch more interest in it from more
> > embedded applications.
>
> Are we going to propose this again "formally" (i.e. sufficiently
> clearly that the committee take note and consider it)?
Heh, we've got lots of people wanting to participate, but no-one really
wanting to make the proposal, so I'll try.
internal kernel key management is becoming a bit of an uncontrolled
mess. We have several sources of trusted keys: the secure boot keyring
(called the db database), the internal keys the kernel was compiled
with, keys in the TPM which are declared to the kernel (this is another
whole world of pain because adding this damaged the current TPM key
management infrastructure from userspace), IMA keys (used for file
integrity measurement), authentication and encryption keys (things like
keys used to encrypt the disk, authenticate NFS roots etc).
There are several issues
1. Population and update policy: How should we populate the default
keyrings and revocation lists? Should we have a built in list of
absolute trust that can never be added to? I think the current
default here is OK: it's populate with the kernel built in keys and
nothing else. If userspace wants to populate with, say, the secure
boot keys, then it can do so from init. An issue here is the
Microsoft signing key, which most Linux people have but which they
wouldn't necessarily consider to be a source of absolute trust.
However, third party driver vendors would like a way to get their
key trusted by the kernel so they can easily supply modules (This
isn't a binary module issue: the code is usually GPL, but the
vendors would like to supply updates asynchronously to the distro
release cycle). We can say their key should be added as part of the
rpm that installs the module, but do users really want this key
adding to the default keyring to be trusted for non-module
operations?
2. Virtualization of the keyrings. The issue here is that you don't
necessarily want root in a container to have full access to the
kernel keyrings. It looks to me like we can use a simple per
namespace virtualization of the key permissions, but I don't think
this should be a topic of discussion before it has been proposed and
discussed on the containers list (which no-one has done yet, in
spite of my requesting).
3. Integration with existing key management infrastructures. The issue
here is things like the gnome keyring and the TPM. The TPM is a
particularly thorny problem: as a key store, the TPM has a very
limited storage space, so something has effectively to swap keys in
and out as they're used. This function is currently performed by a
userspace stack called the TSS. However, the kernel use of the TPM
effectively steals the nvram resource behind the manager's back and
can lead to resource starvation issues in the TPM and unexpected
responses back to the user space TSS. If the kernel wants to use
TPM keys, it needs either to request them properly from the TSS or
we need to pull TPM key management fully into the kernel and make
the TSS use it.
4. Our current key type model is slightly confusing, because we have
about 18 different ones from specific key types: assymetric, secure,
encrypted confused with use case key types like: cifs.spnego,
dns_resolver and grouping types like keyring. We should probably
document them all somewhere and encourage subsystems which don't use
them (like dm crypt) to start. We might also consider discouraging
key type proliferation?
5. root (uid 0) access: should root be able to modify any keyring?
Probably a ton more issues I forgot, but others can add them. A
precursor to this discussion should probably be an introductory
presentation about how this all currently works. If you can't answer
the question how do I add a key to the kernel for a signed module, you
need the introductory session ...
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160727/2ca1321c/attachment-0001.bin>
More information about the Ksummit-discuss
mailing list