Re: kernel module loading vs securelevel

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sat, 16 Oct 2010 13:58:19 -0400
Thor Lancelot Simon <tls%panix.com@localhost> wrote:

>       2) Finish the asymmetric operation support in cryptodev and
>          actually require modules to be signed.  This is basically a
>          superset of #1 above that could get about as complicated as
>          one wanted it to (ugh) but might be worthwhile if kept simple.

You seem to now agree with me that this could be a solution.  It
indeed requires more work, but it also has advantages: not having to
care about module location or their mutability; allowing delegation
(multiple trusted public keys allow to verify signatures of various
trusted third parties), among others.

A developer working on a module only has to sign it without any further
trouble to test it (assuming he included his public key in the kernel
image).  No need to go change the flags of a hashes file (a plausible
point of failure anyway), update it, make it immutable again, etc.

Of course a serious problem would still exist if the kernel's database
of trusted keys could be modified.  An effort could be made so that
these cannot be modified at runtime but only at kernel image build
time, requireing a reboot, and those that care can manage to load the
kernel image from a read-only source.

To simplify things, couldn't X.509 parsing strictly be done by the
userland build infrastructure?  The list of trusted keys can be stored
in a simple binary format as part of the kernel image, and the module
signature can also be stored as a simple binary format as part of that
module.  If you want to be able to revoke an existing key at runtime,
support the use of subkeys and CAs and the like, things suddenly become
more complex, but I don't think it's necessary for this.

Even a simpler system with no trusted entities list could make use of
this: a random key pair could be generated at build time, the public
part of it the only stored key in the kernel image, and all modules
signed with the private part of that key, which then gets discarded...
Although the only advantage over veriexec-like hashes in this case
would be reduced kernel image read-only data segment (i.e. one 1024-bit
public key stored instead of n * 160-bit hashes).
-- 
Matt