Digitally Signed Binaries w/ Kernel support, etc.

Christian S.J. Peron csjp at FreeBSD.org
Thu Apr 10 15:19:36 UTC 2008


On Thu, Apr 10, 2008 at 04:39:56PM +0200, Kris Kennaway wrote:
[..]
> 
> csjp@ had a mac_chkexec module that looks like it was never committed.
> 
> http://groups.google.com/group/mailing.freebsd.hackers/msg/074eec7def84c52b
> 
> Shouldn't be hard to update it.
> 

Just a few notes:

- This isn't really "binary signing" per se, I associate a cryptographic
  checksum with a shared object, executable, shell script etc... Then
  if you try to mmap the shared object into the address space, or execute
  the executable object (after it was back-doored with malicious code), it
  will deny it (assuming the system is in "enforce" and not in "learning"
  mode).  Also, new binaries (ones without checksums associated with them)
  would not be permitted to execute.

  True binary signing basically requires that the signature is part of the
  executable format. for example: embedding a certificate in the ELF
  structure. This would allow us to distribute binaries across systems.

  In my model, we are using extended attributes, which offers security for
  the local system only (but still useful if the intent is to allow certain
  users to upload new binaries, and protect against exploits or backdoored
  binaries).

- Mathew Dodd and I started working on a "bignum" library for the kernel
  so we could perform the arbitrary precision arithmetic required for
  various PKC operations to implement proper "signing", and for the most
  part it worked, but I think there were some edge cases where there are
  problems. (Since there is some interest here, I could be convinced to
  pickup the project again).

- I have not committed this because I do not want to import the userspace
  utilities required to manage the checksums.  In retrospect, I should
  have stored the checksums in the MAC label.  I intend to correct this,
  and it's likely I could add it to base once this is done.

  The code listed in the link above is not likely to compile due to some
  MAC entry point renaming that was completed. However I should be able to fix
  this pretty quickly and send a follow up email here for anyone who is
  interested in experimenting.

  http://people.freebsd.org/~csjp/mac/trustedexec.png

  Describes it's operation at a high level.


More information about the freebsd-stable mailing list