Re: Release DigSig 0.1: LSM module checking digital signatures before loading the binaries

From: Makan Pourzandi (Makan.Pourzandiat_private)
Date: Thu Sep 18 2003 - 07:18:49 PDT

  • Next message: Makan Pourzandi: "Re: Release DigSig 0.1: LSM module checking digital signatures before loading the binaries"

    Crispin Cowan wrote:
    > Makan Pourzandi wrote:
    >> Release of digsig.0.1
    >> We implemented a kernel module using LSM hooks for 2.5.66
    >> which checks signatures before running a binary. The main goal is to 
    >> insert digital signatures inside the ELF binary
    >> and verify this signature before loading the binary. 
    > This sounds *very* similar to CryptoMark 1, which we released in 2001 
    > It also used GPG 
    > to apply public key signatures to executables 
    Hi Crispin.
    Thank you for your feedback. Actually, digsig is a complete 
    re-imlpementation. We began from the scratch. We had a look on the 
    CryptoMark source code and we decided not to use your code for several 
    reasons. At the time we began the development (several months ago), it 
    was not clear to us if this code is maintained or not (I believe that 
    code has not been changed since 2001, we wanted to use the latest crypto 
    modifications in linux kernel, our code uses the cryptoAPI in the kernel 
    2.5.X series). We also decided to use Bsign to sign binaries. IMO, Bsign 
    does a good job for signing the banries, reusing their code helps to 
    avoid developing user space tools by our own. And the last but not the 
    least, we think that using your experience with CryptoMark, we could 
    avoid  some problems you may have encountered and do a better job in 
    designing and writing our own  code. Time and community feedback will 
    show us if we managed to do so or not. 
    >> However, in order to reduce the overhead in the kernel, we took only the
    >> minimum code necessary from GPG. We took only the MPI (Multi Precision
    >> Integer) source code and the RSA crypto source code. This helped much
    >> to reduce the amount of code imported to the kernel in sourc code of
    >> the original (only 1/10 of the original gnupg 1.2.2 sourc code has
    >> been imported to the kernel module).
    > We did that, too. Is digsig a compelte re-implementation? Or is it 
    > based on the CryptoMark release? Either is plausible, as we did not 
    > widely publicize this result (we regarded it as a failed attempt due 
    > to high overhead) but we do know that some people tried to build on it.
    >> Performances
    >> ===============
    >> This is release 0.1. We have done some benchmarks.
    >> We ran lmbench on a Pentium IV, 2.4 GHz, 500 mega bytes of memory,
    >> running Linux 2.5.66. Our benchmarks show that the execution time
    >> (exec function call) multiplies by a factor of 4 when the module is
    >> loaded (no changes for fork call, as the binary is not loaded into
    >> memory). 
    > We found the performance penalties to be *substantial*, typically in 
    > the 500% slowdown range. The problem is that the cost of digital 
    > signatures is more or less linear in the size of the program, mostly 
    > to compute the MD5 of the program. Small programs tend to be 
    > short-lived, while larger programs tend to be longer-lived, and the 
    > net result was 200% to 500% slowdown across the board. I suggest you 
    > try doing a kernel build with and without digsig and see what it does 
    > to your performance overhead. If you don't see the same overhead that 
    > we did, then I'd be very curious about the details.
    We'll do, for time being we have been trying to use rather lmbench for 
    tests, but I believe you have a good idea, we're currently running the 
    tests as soon as we come up with some synthesis of the results I'll post 
    it to the mailing list.
    > We then went and did an OpneSSL implementation. Unfortunately, that is 
    > not releasable, because OpenSSL uses the 4-clause license, which is 
    > asserted to be incompatible with the kernel's GPL by some significant 
    > linux kernel authors.
    > Thanks,
    >    Crispin
    That's the main reason we avoided the use of OpenSSL, I hoped that 
    somehow I would be wrong and during the discussions someone will come 
    with a brilliant idea to make possible the use openssl. It seems that it 
    was just wishful thinking.

    This archive was generated by hypermail 2b30 : Thu Sep 18 2003 - 07:13:06 PDT