Re: [PATCH 01/19] User-space API definition

[Kyle Moffett]

On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac <mitr@xxxxxxxxxx> wrote:
> ----- "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxxx> wrote:
>> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
>> > I have seriously considered the keyring API, and this is what I came
>> up with - but I'd love to be shown a better way.
>>
>> FWIW adding a second key management system to the kernel is
>> totally out of the question.
>>
>> If the existing system doesn't work for you, find a way to build
>> on it so that it does. ÂAdding a second system that pretty much
>> does the same thing is unacceptable.
> It does _not_ do the same thing, same as ramfs and file descriptors do not do the same thing although they are both related to files.
>
> The kernel keyring service is basically a system-wide data storage service. Â/dev/crypto needs a quick way to refer to short-lived, usually process-local, kernel-space data structures from userspace.

The problem with the approach you're proposing is that we then have
two entirely separate classes of keys.  First we have the existing
keyring class, which can be securely and revokably passed between
different processes with limited rights, but cannot be handed up to
the kernel's cryptoapi.  Then we have your new class, which are
anonymous keys with a brand new security model (which doesn't even
have LSM hooks yet) and which cannot be referenced by name.

Another potential issue is that keys are never actually "unnamed", in
that sense.  If encryption keys truly were "anonymous" then you would
find it impossible to reliably decrypt the data on the other end.  For
example, every RSA private key should be indexed either by the X.509
DN or for bare SSH keys by the public modulus information.  Even
transient SSL session keys are always put into an SSL session cache by
apache or whatever to allow them to be reused across multiple TCP
streams!  So I would argue that an SSL implementation that uses this
should actually create or use a keyring specifically as an SSL session
cache (with keys indexed by SSL session ID).

It then becomes trivial to share an SSL session cache between 3
independent HTTPS server programs from different vendors, such that
the compromise of *any* of the processes would not in any way
compromise the security of the session keys.  This would be especially
true if the session keys are actually generated by a keyring+cryptoapi
operation in the kernel.

So my recommendation would be to create some new operations of the
existing keyring code:

(1) If you *really* care about anonymous transient keys that are not
identified by an SSL session ID or similar, then add a keyring
operation for "create an anonymous key in keyring X, where the kernel
creates a proper temporary name".  An SSL implementation would default
to using the process-local keyring, which means that everything would
automatically go away on process exit.

(2) Add cryptoapi hooks to automatically register keyring key types
based on the loaded cryptoapi modules.

(3) Add any necessary keyring operations for efficiently performing
zero-copy cryptoapi calls using those key types.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/