Kernel module to deny execution of unsigned binaries?

[Christian S.J. Peron]

Max Laier wrote:
> On Wednesday 30 August 2006 20:28, 473219 at googlemail.com wrote:
>   
>> Is it possible in TrustedBSD to prevent the execution of binaries
>> whose path names + checksums are not listed in an "Approved" list?
>>     
>
> There is some code from Christian (CCed) here: 
> http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/trustedbsd/mac/sys/security/mac%5fchkexec&HIDEDEL=NO
>
> AFAIR, it uses extended attributes to store a hash of the executeable that 
> is checked upon execution.  Certainly Christian has more details and a 
> status.
>
>   
Here are the highlights worth noting for mac_chkexec:

mac_chkexec prevents the execution of (1) binaries, (2) shared objects 
and (3) kernel modules which have been modified (back doored with 
trojans et al). Each binary has a cryptographic checksum associated with 
it, stored as an extended attribute to the file itself.

How it works is when the binary is executed, or when a shared object is 
mmap()'ed into the address space of the process, the kernel calculates 
the checksum of the data, and compares it against the checksum 
referenced by the inode, if the checksums don't match, the policy 
rejects access.

You can either force the calculation and storage of checksums using 
setfhash(8), or if the policy is loaded but not being enforced, i.e. 
"learning mode", the checksum will be calculated and stored when the 
executable is activated. This allows you to set a baseline security 
model for your system simply by just booting and executing all the 
relevant binaries you wish to protect. It should also be noted that if 
an executable does not have a checksum associated with it, and the 
policy is being enforced, execution will be denied.

You can also set dependencies, i.e. don't allow ipfw to execute if 
/etc/services and /etc/protocols has been modified.

There is also an optional cache that can be enabled, which makes the 
performance overhead of this policy minimal.

Currently, SHA1 and MD5 is supported.

Some of draw backs:

(1) You need to reset system baselines after updates (and only 
privileged users can do it)
(2) It depends on UFS extended attributes, so currently things like NFS 
is not supported, although, NFS is not really known for it's integrity.

Ideally, this would be used with an integrity policy like mac_biba. I 
run this configuration on some production machines and it does well.  
Currently this is found in the trustedbsd-mac branch, and as far as I 
know, it's stable. If you have any further questions or want any 
additional help, dont hesitate to ask. We have discussed brining this 
into base, but we are currently still hashing out the details associated 
with the life of MAC modules in general.

Following is a flow chart on how this policy works logically, which 
should be fairly up to date:

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


-- 
Christian S.J. Peron
csjp at FreeBSD.ORG
FreeBSD Committer
FreeBSD Security Team