Preliminary Linux Key Infrastructure 0.01-alpha1

Preliminary Linux Key Infrastructure 0.01-alpha1

[Kyle Moffett]

Preliminary Linux Key Infrastructure 0.01-alpha1:

I'm writing a key/keyring infrastructure for the Linux kernel. I've got 
some of the
basic infrastructure done, and I'd like any comments on it that you may 
have.

Please note that as yet none of this has been even compile tested, it 
has
errors galore, and is still very incomplete.  I have only worked on the 
in-kernel
parts of the infrastructure, user-space interfaces and keyctl are on my 
TODO
list. :-D

See below for my current status:

That said, here's a link:
http://www.tjhsst.edu/~kmoffett/lki.tar.bz2

Completed:
	lki_key_t & methods
		A simple key, with a description and a BLOB
	lki_keytype_t & methods
		A module-registered key type description including callbacks
	lki_key_hash_{add,remove,search}
		Lookup up keys by number

In Progress:
	lki_keyring_blob_t & methods
		A special-case of a key. Just needs add and remove key methods
	permissions model
		On hold while I learn more about POSIX ACLs and stuff
	lki_key_handle_t
		This is my next task, it is barely started

TODO:
	keyctl:
		The syscall that makes it all possible
	keyfs:
		keys by number: On hold while I learn more about filesystems :-D
	libinuxkeys:
		A user-space library linked using "gcc -linuxkeys" :-D

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[Bernd Eckenfels]

In article <65EFF013-DEAA-11D8-9612-000393ACC76E@mac.com> you wrote:
> Preliminary Linux Key Infrastructure 0.01-alpha1:

What kind of keys you want to store and what are they used for?

Gruss
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[Kyle Moffett]

On Jul 25, 2004, at 23:21, Bernd Eckenfels wrote:
> In article <65EFF013-DEAA-11D8-9612-000393ACC76E@mac.com> you wrote:
>> Preliminary Linux Key Infrastructure 0.01-alpha1:
>
> What kind of keys you want to store and what are they used for?

My code is in followup to the LKML discussion here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=108700802812286&w=2

The goal is simply to put encryption keys in the kernel so they can be
used by a variety of systems, AFS, NFSv4, dm-crypt, CryptoAPI, etc.

There was also a bit of a discussion on OpenAFS-devel about it too.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[J. Bruce Fields]

On Mon, Jul 26, 2004 at 12:40:57AM -0400, Kyle Moffett wrote:
> On Jul 25, 2004, at 23:21, Bernd Eckenfels wrote:
> >In article <65EFF013-DEAA-11D8-9612-000393ACC76E@mac.com> you wrote:
> >>Preliminary Linux Key Infrastructure 0.01-alpha1:
> >
> >What kind of keys you want to store and what are they used for?
> 
> My code is in followup to the LKML discussion here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=108700802812286&w=2
> 
> The goal is simply to put encryption keys in the kernel so they can be
> used by a variety of systems, AFS, NFSv4, dm-crypt, CryptoAPI, etc.
> 
> There was also a bit of a discussion on OpenAFS-devel about it too.

How does this compare with the patches posted by Erik Jacobson and by David
Howells?

--Bruce Fields

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[Pavel Machek]

Hi!

> In Progress:
> 	lki_keyring_blob_t & methods
> 		A special-case of a key. 
See CodingStyle, naming structure *_blob_t is ugly.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[James Morris]

On Sun, 25 Jul 2004, Kyle Moffett wrote:

> Preliminary Linux Key Infrastructure 0.01-alpha1:
> 
> I'm writing a key/keyring infrastructure for the Linux kernel. I've got
> some of the basic infrastructure done, and I'd like any comments on it
> that you may have.

Firstly, it might be useful for other developers if you could write up a
brief rationale about this feature, why it's needed and why this is a good
solution.  I do know of a few projects which could make use of keyrings:

 - cryptfs (Michael Halcrow)
 - afs
 - module signing (David Howells/ Arjan)

Are there others (with running code, merged or potentially mergable) ?

Does your design cater for all needs?

I think I heard that Greg-KH had some keyring code already, so there may
be some existing code floating around.

To get more people to look at the code, I'd suggest that you get it 
running and prepared as a patch to the mainline kernel.  It will also help 
if you follow Documentation/CodingStyle and use more idiomatic kernel 
development practices.

For example, typedefs are generally frowned upon (but perhaps acceptable
to improve readability of complex function pointer stuff).

You don't need to cast the result of kmalloc:

	key = (lki_key_t *)kmalloc(sizeof(lki_key_t),GFP_KERNEL);

should be:

	key = kmalloc(sizeof(lki_key_t),GFP_KERNEL);

Avoid using sizeof(some_type) for things like the above, use the actual 
object itself:

	key = kmalloc(sizeof(*key), GFP_KERNEL);

(in case the type of *key changes some day).

Use wrapper functions like wait_event_interruptible() instead of rolling 
your own.

It's better (IMHO) to have one exit path in a function, to clarify error
handling, locking, and make it easier to audit the code.  e.g. in
lki_key_used_list_allocate(), you grab a lock then have several return
points with no unlock.

Having some real code which uses the framework will also be good.


> TODO:
> 	keyctl:
> 		The syscall that makes it all possible

Why would you need a syscall?

> 	keyfs:
> 		keys by number: On hold while I learn more about filesystems :-D

What does this mean?

I would imagine that the entire userspace API would be filesystem based.  
e.g.  you could load the keys for module signature checking during boot by
writing them to a node like:

cat keyring.txt > /keyrings/modsign/keys

Disable further changes:

echo "0" > /keyrings/modsign/write

You could manage per process credentials via /proc/self/something


- James
-- 
James Morris
<jmorris@redhat.com>

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]


> I think I heard that Greg-KH had some keyring code already, so there may
> be some existing code floating around.

actually it's David Howells; he has been working on an implementation
for quite some time and posted it to lkml a bunch of times and
incorporated the reviews.... it would be interesting to see why and how
your approaches are different...

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[Kyle Moffett]

On Jul 29, 2004, at 01:58, James Morris wrote:
> Firstly, it might be useful for other developers if you could write up 
> a
> brief rationale about this feature, why it's needed and why this is a 
> good
> solution.  I do know of a few projects which could make use of 
> keyrings:

Hrm, oops!  Somehow my readme got left out of the tarball, I'll upload
another revision sometime today.

Basically, I put a generic "encryption key" type in the kernel with 
functions
to manipulate it.

>  - cryptfs (Michael Halcrow)
>  - afs

These two, as well as NFSv4 and possibly others could benefit from
having user accessible keys/keyrings in the kernel

>  - module signing (David Howells/ Arjan)

This is the hard one, because this is only really useful for a kernel 
that
doesn't allow unsigned modules, which means that you need to put a
key in the kernel when it is compiled, and possibly sign the entire 
kernel
with said key.  Such a key shouldn't be modifiable in any way.

> Are there others (with running code, merged or potentially mergable) ?
>
> Does your design cater for all needs?
That's what I'm asking :-D.  There was a big discussion a week or two
ago on the LKML "In-kernel Authentication Tokens (PAGs)".  This is an
outgrowth of that discussion.

> I think I heard that Greg-KH had some keyring code already, so there 
> may
> be some existing code floating around.
I think that was David Howells, and I've looked at his code extensively.

> To get more people to look at the code, I'd suggest that you get it
> running and prepared as a patch to the mainline kernel.  It will also 
> help
> if you follow Documentation/CodingStyle and use more idiomatic kernel
> development practices.

Yeah, what I have now is one weekend's worth of work just throwing it
together to get myself started.  I may have something new tomorrow, but
if not I'm gone for a week and I'll have something when I get back.


> For example, typedefs are generally frowned upon (but perhaps 
> acceptable
> to improve readability of complex function pointer stuff).
>
> You don't need to cast the result of kmalloc:
>
> 	key = (lki_key_t *)kmalloc(sizeof(lki_key_t),GFP_KERNEL);
>
> should be:
>
> 	key = kmalloc(sizeof(lki_key_t),GFP_KERNEL);
>
> Avoid using sizeof(some_type) for things like the above, use the actual
> object itself:
>
> 	key = kmalloc(sizeof(*key), GFP_KERNEL);
>
> (in case the type of *key changes some day).

Ok, thanks.  In the past some compilers had given we warnings when I
didn't cast, so I wasn't sure.

> Use wrapper functions like wait_event_interruptible() instead of 
> rolling
> your own.

I needed a specialized version that dropped a spinlock after adding 
itself
to the waitqueue and before sleeping, then relocking before checking the
condition.  Is there a better way to do what I need there?

> It's better (IMHO) to have one exit path in a function, to clarify 
> error
> handling, locking, and make it easier to audit the code.  e.g. in
> lki_key_used_list_allocate(), you grab a lock then have several return
> points with no unlock.

Yeah, my error handling is a real mess and needs to be cleaned up.

> Having some real code which uses the framework will also be good.

Yep.

>> TODO:
>> 	keyctl:
>> 		The syscall that makes it all possible
>
> Why would you need a syscall?

The only way to _manipulate_ keys is by first getting a key handle.
To get a key handle you can open the file "keyfs/<keyid>/control"
for a specific key number, or you can just get a key handle straight
from the KEYCTL_CREATE call, or from the KEYCTL_GET call, or
from a couple other calls.  A key handle is just a file handle with a
special struct key_handle attached to it to provide access to the
key behind it.

>> 	keyfs:
>> 		keys by number: On hold while I learn more about filesystems :-D
>
> What does this mean?

A file system somewhat like the following:

keyfs/
	<keyid>/
		control
		desc
		blob
	<keyid>/
		control
		desc
		blob
		ring/
			<keyid>	=>	../../<keyid>
			<keyid>	=>	../../<keyid>
	<keyid>/
		[...]

> I would imagine that the entire userspace API would be filesystem 
> based.
> e.g.  you could load the keys for module signature checking during 
> boot by
> writing them to a node like:
>
> cat keyring.txt > /keyrings/modsign/keys
>
> Disable further changes:
>
> echo "0" > /keyrings/modsign/write
>
> You could manage per process credentials via /proc/self/something

There was a big discussion about user interface, see the earlier thread
"In-kernel Autnetication Tokens (PAGs)" for more info.

Thanks for your comments!

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[J. Bruce Fields]

On Thu, Jul 29, 2004 at 08:43:10AM -0400, Kyle Moffett wrote:
> On Jul 29, 2004, at 01:58, James Morris wrote:
> >I think I heard that Greg-KH had some keyring code already, so there 
> >may
> >be some existing code floating around.
> I think that was David Howells, and I've looked at his code extensively.

Could you summarize the differences?  Would you please consider posting
patches against his patches instead of starting over from scratch?

I'd really like to start looking at these patches and figure out how
we'd use them for NFS/rpcsec_gss, but this is made more difficult by
the fact that there are now 2 or 3 different pieces of code floating
around now that all claim to do PAG/keyring stuff.

--Bruce Fields

Re: Preliminary Linux Key Infrastructure 0.01-alpha1

[Kyle Moffett]

On Jul 29, 2004, at 10:25, J. Bruce Fields wrote:
> Could you summarize the differences?

- David Howells' patch has a lot of special cases, a keyring isn't just
another registered keytype, whereas I use a flexible enough keytype
system that "keyrings" are normal keys with a key->type pointer to
struct key_type keyring_type = { ... };

- David Howells' patch isn't built to really allow processes to safely
share keys with each other, whereas I have a separate type called
"struct key_handle" that can be copied and still properly revoked.
(All the copies of the handle are revoked when the handle itself  is
revoked, but not the one that created said handle)

> I'd really like to start looking at these patches and figure out how
> we'd use them for NFS/rpcsec_gss, but this is made more difficult by
> the fact that there are now 2 or 3 different pieces of code floating
> around now that all claim to do PAG/keyring stuff.

Right now it's still kind of like the scheduler stuff, it's easy to 
write
your own version, so there are a couple people maintaining their
own code to try out new ideas.  Personally I am not quite happy
with the architecture of some parts of David Howells' code, and I
wanted more architectural freedom so I started my own patch. In
a couple weeks or so I'll be done fooling around in my own little
world trying out ideas and maybe have some reasonably decent
patches.

I'll be gone next week, but I hope to continue this discussion
when I get back.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------