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------


-
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/