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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTi=kF880O_DuemgRPajvs3diyuvK8s4Ap04+kPzL@mail.gmail.com>
Date:	Mon, 6 Sep 2010 16:42:07 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Nikos Mavrogiannopoulos <n.mavrogiannopoulos@...il.com>
Cc:	Miloslav Trmac <mitr@...hat.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	linux-crypto@...r.kernel.org, Neil Horman <nhorman@...hat.com>,
	linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 01/19] User-space API definition

On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/