On Sat, 16 Oct 2010 13:58:19 -0400 Thor Lancelot Simon <[email protected]> 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
