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

[Kyle Moffett <kyle@moffetthome.net>]

On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos@gmail.com> wrote:
> On 09/06/2010 08:00 PM, Kyle Moffett wrote:
>>> 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.
>
> I don't think this is the case. The NCR does not store any keys nor
> retrieves them. It does delegate the burden of that to userspace
> application. NCR exports a wrapped version of the key and the userspace
> application stores it. It could use the keyring to store the keys or
> could directly store them in the filesystem.

Hmm, I'm confused.  You say "The NCR does not store any keys nor
retrieves them", but ~75% of your API is specifically related to
storing keys into kernel memory or retrieving them out of kernel
memory.  Specifically, putting keys into and out of the kernel and
passing them around between processes is the *whole point* of the
keyring API.

So let me ask for some clarification:

You talk a lot in the patches about the API itself, but what is the
intended *use-case* for NCR?

Is it to provide a back-end for code such as enhanced-security OpenSSL
libraries?  For example, a privileged process would loads a key from
disk into the kernel, then fork the unprivileged SSL server process?

Is it just a canonical interface for userspace to encrypt or decrypt
data using the kernel's CryptoAPI?

Cheers,
Kyle Moffett