Date: Wed, 13 Sep 2006 13:58:27 -0400 From: Joshua Brindle <method@gentoo.org> To: "Christian S.J. Peron" <csjp@FreeBSD.org> Cc: trustedbsd-discuss@freebsd.org Subject: Re: Kernel module to deny execution of unsigned binaries? Message-ID: <450846C3.7090200@gentoo.org> In-Reply-To: <44F64812.9030107@FreeBSD.org> References: <e782d7390608301128s53c02cedhb73f12a590d2798d@mail.gmail.com> <200608302101.46323.max@love2party.net> <44F64812.9030107@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Christian S.J. Peron wrote: > 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 > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?450846C3.7090200>