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-next>] [day] [month] [year] [list]

Message-ID: <169108422.1009631283788251084.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Date:	Mon, 6 Sep 2010 11:50:51 -0400 (EDT)
From:	Miloslav Trmac <mitr@...hat.com>
To:	Herbert Xu <herbert@...dor.hengli.com.au>
Cc:	Kyle Moffett <kyle@...fetthome.net>, linux-crypto@...r.kernel.org,
	Nikos Mavrogiannopoulos <n.mavrogiannopoulos@...il.com>,
	Neil Horman <nhorman@...hat.com>, linux-kernel@...r.kernel.org,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 01/19] User-space API definition

----- "Herbert Xu" <herbert@...dor.hengli.com.au> wrote:
> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
> >
> > I can see almost no overlap between the two sets of requirements. 
> Probably the only common use case is handling session keys (e.g. keys
> used in a kerberos ticket), which should be stored in the kernel for
> the duration of the session, made available to each process in the
> session, and available as keys for kernel crypto.  Such keys will be
> in the minority, though, and it seems to me the best approach for
> handling these is to allow key export/import from/to keyring keys in
> addition to export/import from/to data in userspace: the long-term
> storage would be handled by the existing keyring API, which stores the
> key as unformatted binary data, and import into the crypto context
> would convert the key into the internal representation more suitable
> for crypto.
> > 
> > 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.

Imagine that instead of
    thread = clone(..., CLONE_THREAD);
you needed to do
    thread_fd = mkstemp("/proc/XXX");
    fork(thread_fd);
That's how "just using the existing keyring" would look like.

Adapting the existing keyring to match the /dev/crypto use case better would make the keyring API at least 25% larger, and introduce completely different key identification and lifetime semantics for a set of keys.

If you can see a way the two can be cleanly integrated, please don't just tell us that we have to do it, tell us how.
 
> Also, the key management for secret keys that you've added should
> not be the only mode offered to the user.  Most people do not need
> the separation between key setting and encryption/decryption.
The "key ID" is not embedded into encryption operation requests (it uses a struct nlattr), so it would be quite possible to supply the raw key instead.
    Mirek
--
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/