According to Michael Graff:
>
>Then, you could store the keys you accept in the kernel, have the
>binaries contain a signature and the hash (along with other things you
>might want to keep around about the source) and let the kernel verify
>the signature as trusted or untrusted.
>

This is almost what my code does except that:

a) there is no modification to the binary, the fingerprints are stored
in a separate file.  I am trying hard to steer clear of any
modifications to binaries as I believe that this will cause
headaches.  You could distribute the entire install set with
a valid fingerprint file as part of it.  As long as people verify the
entire set as having a valid fingerprint then they can be reasonably
sure the system has not been tampered with in transit and that the
binaries they are running are what they think they are running.
Either that or just provide a script that will generate the
fingerprint file for you - this is not difficult and it does not take
an inordinate amount of time to run.

b) The decision for trusting/not trusting a binary is made when the
fingerprint file is updated.  Once the decision has been made and the
file updated then the binary is trusted and will be validated before
running.  You may, if you wish, run at a lower securelevel that will
report signature mis-matches but still run the binary.


-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================