Date: Wed, 30 Aug 2006 21:23:14 -0500 From: "Christian S.J. Peron" <csjp@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: trustedbsd-discuss@freebsd.org Subject: Re: Kernel module to deny execution of unsigned binaries? Message-ID: <44F64812.9030107@FreeBSD.org> In-Reply-To: <200608302101.46323.max@love2party.net> References: <e782d7390608301128s53c02cedhb73f12a590d2798d@mail.gmail.com> <200608302101.46323.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier wrote: > On Wednesday 30 August 2006 20:28, 473219@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@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44F64812.9030107>