Difference between revisions of "Projects/Kernel subset"

Latest revision as of 17:10, 7 August 2012

Overview

Filesystem implementations using Kerberos, particularly NFS, typically establish a GSS security context in userspace, transport that context into the kernel, and use the context to exchange messages. To perform this task, kernels need a subset of the gss-krb5 code.

The purpose of this project is to create build infrastructure to help identify and preserve the independence of the necessary code subset, in order to make the job of kernel integrators easier.

Design

A new directory util/gss-kernel-subset contains build logic to create a subset library named libkgss, code specific to the kernel subset, and test code.

The kernel subset will contain files from lib/gssapi/krb5 and lib/gssapi/generic. No files from libkrb5 will be included, as none are needed for the kernel subset (a few krb5_free() functions are required, but their definitions are easily duplicated). Because almost all of the crypto library is required by the kernel subset, libkgss will depend on libk5crypto rather than incorporating its contents. A readme file will describe the small portions of the crypto library which could be excised if necessary, and will also explain what parts of the crypto library should be replaced using kernel-specific crypto and PRNG functions.

A test program will exercise the code necessary to export a Lucid security context, import it using libkgss, and wrap/unwrap/get_mic/verify_mic messages, as well as wrap and unwrap messages using gss_wrap_iov and gss_unwrap_iov().

The kernel subset is built with -DKRB5_KERNEL. Currently this symbol is used only to disable the functionality of save_error_info() in the krb5-gss code, eliminating a dependency on krb5_get_error_message() and krb5_set_error_message().

Future Consideration

The kernel subset relies on k5-int.h and all of its subsidiary headers, some of which are not needed in the kernel subset. It could be helpful to reorganize k5-int.h so that it is just a container for a set of subsidiary headers, and then make the kernel subset include only the subsidiary headers they need.

It might be possible to reorganize libk5crypto to make it easier to excise the parts not needed for the kernel subset (string-to-key, PRF, RFC3961 token construction for DES, DES3 and RC4 enctypes). It's not at all obvious what form that reorganization would take. The kernel subset build system would still need to essentially copy 90% of the libk5crypto build system, including the parts which might not be present in a real kernel integration (such as lib/crypto/builtin and lib/crypto/krb/prng_fortuna.c).

Relevant Mailing List Threads

http://mailman.mit.edu/pipermail/krbdev/2011-April/009974.html

Release Notes

Developer experience:

• In the build system, identify the source files needed for per-message processing within a kernel and ensure that they remain independent.