From owner-trustedbsd-discuss@FreeBSD.ORG Wed Sep 13 17:58:44 2006 Return-Path: X-Original-To: trustedbsd-discuss@freebsd.org Delivered-To: trustedbsd-discuss@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A591116A403; Wed, 13 Sep 2006 17:58:44 +0000 (UTC) (envelope-from method@gentoo.org) Received: from exchange.columbia.tresys.com (tresys.irides.com [216.250.243.126]) by mx1.FreeBSD.org (Postfix) with SMTP id 24DFF43D6E; Wed, 13 Sep 2006 17:58:40 +0000 (GMT) (envelope-from method@gentoo.org) Received: from [127.0.0.1] ([10.1.13.53]) by exchange.columbia.tresys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 13:58:37 -0400 Message-ID: <450846C3.7090200@gentoo.org> Date: Wed, 13 Sep 2006 13:58:27 -0400 From: Joshua Brindle User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <200608302101.46323.max@love2party.net> <44F64812.9030107@FreeBSD.org> In-Reply-To: <44F64812.9030107@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0637-0, 09/11/2006), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 13 Sep 2006 17:58:38.0144 (UTC) FILETIME=[3D449400:01C6D75E] Cc: trustedbsd-discuss@freebsd.org Subject: Re: Kernel module to deny execution of unsigned binaries? X-BeenThere: trustedbsd-discuss@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2006 17:58:44 -0000 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