Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 00/23] Crypto keys and module signing | Date | Fri, 22 Jun 2012 12:03:13 +0100 |
| |
Rusty Russell <rusty@rustcorp.com.au> wrote:
> 1) No userspace needs to be modified to use the appended signature. > modprobe doesn't. depmod doesn't. Even strip doesn't (not that > that's much use).
Anything that currently automatically strips the module: mkinitrd perhaps?
If we use a new system call, then the list includes a few more things.
Your idea of providing multiple variants of the module, each signed and each with different levels of strippedness makes things more complicated - both at build/package generation time and at usage time (where 'use' may be loading the module or packaging it into a initrd).
> 2) It's far easier to add an appended signature than to add an elf > section.
That's not true. That bit of complexity in my implementation comes because I'm adding it as an ELF Note - which someone suggested I should do instead of just using an unstructured section.
If we reverted to an unstructured section, it's just one objcopy command, eg:
objcopy \ --add-section .modsign=/etc/redhat-release \ --set-section-flags .modsign=load \ /bin/ls /tmp/ls
And for debugging purposes, removing it is:
objcopy \ -R .modsign \ /bin/ls /tmp/ls
> 3) It's far easier to generate an appended signature than to generate > a signature for the module which will change when you add the > signature section (roughly: gpg --sign module.ko > sig && echo > '@@sig@@ >> module.ko && cat sig >> module.ko).
You would be better off putting the magic number last and including a length field right before. That's much more efficient and much simpler.
> 4) It's trivial to verify a module with an appended signature before you > touch it. With a section you need to carefully parse the module, > make sure you don't include the could-be-modified stuff in the > signature, and avoid any possible overflows or exploits.
I have to say that here Rusty is correct. If the signature is embedded in the ELF, then the ELF needs a bit of careful checking first. But, excluding the crypto bits which are the same in all cases, I managed to get the entire ELF parser/checker/canonicaliser, digest extractor and policy determiner down to a little over 2K of x86_64 code.
Since the ELF loader/linker has to parse much of this stuff anyway, it might be possible to combine the two to some extent.
> 5) It wasn't just that they wanted an elf section. They wanted the > signature to work against both a stripped and unstripped module, so > only the unstrippable parts of the module were signed.
Yes. Those are the bits that the module loader needs...
This is quite a good a trade off. It simplifies building and installation a lot. There is only one binary for each module. That binary can be stripped quite aggressively - any strip that would ordinarily leave the module functional won't affect the signature verification. Any content or metadata change that affects the module's operational code and data is detected.
> > And I think we really want the ability to have multiple signatures, the > > whole "chain of trust" thing that is needed will work out much better if > > multiple signatures are allowed. Putting it in an elf section allows > > this to work out easier, right? > > Not at all. Multiple appended signatures is trivial. Figuring out the > semantics (do they chain, or is any one sufficient?), well that's the > same whether you're talking about an ELF section or not.
Agreed, it makes no difference either way.
But it doesn't necessarily work with a new syscall that has an extra pair of args for passing a signature. The kernel really wants to have all the available sigs available in one go so that it can implement its policy (which might be to panic in FIPS mode).
David
| |