Kernel module to deny execution of unsigned binaries?

[Joshua Brindle]

Christian S.J. Peron wrote:
> 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
>
>
Its worth noting that there was a long thread about this on the linux 
security modules list this year concerning an LSM that did binary 
signature checking (digsig) and was decidedly not useful for a number of 
reasons, primarilly because you can implement an ELF loader in any 
interpreted language when the interpreter is signed.

http://marc.theaimsgroup.com/?l=linux-security-module&m=114581034926854&w=2