From owner-trustedbsd-discuss@FreeBSD.ORG Thu Sep 7 01:27:01 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 AB2A316A4DA for ; Thu, 7 Sep 2006 01:27:01 +0000 (UTC) (envelope-from 473219@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF7BB43D6E for ; Thu, 7 Sep 2006 01:26:54 +0000 (GMT) (envelope-from 473219@googlemail.com) Received: by nf-out-0910.google.com with SMTP id n29so375439nfc for ; Wed, 06 Sep 2006 18:26:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tfGWvINXqLEhWqVCuDp3H0ZCO/wOCzTYgECW+tDjFCpapR+QvzWewvJOf6dxsxbjeG3Ir91UbcIGSyUejsbVDSS0sev8NF4HhF7scaJeNnBIxbzduH4W8/L58UMQecdAiQj74YaB1GsME4um9sdp+ZOujYlOA5SBUpGqgfMaI/k= Received: by 10.49.19.18 with SMTP id w18mr1842949nfi; Wed, 06 Sep 2006 18:26:53 -0700 (PDT) Received: by 10.49.65.10 with HTTP; Wed, 6 Sep 2006 18:26:53 -0700 (PDT) Message-ID: Date: Thu, 7 Sep 2006 02:26:53 +0100 From: 473219@googlemail.com To: "Christian S.J. Peron" In-Reply-To: <44F64812.9030107@FreeBSD.org> MIME-Version: 1.0 References: <200608302101.46323.max@love2party.net> <44F64812.9030107@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Thu, 07 Sep 2006 01:27:01 -0000 On 31/08/06, Christian S.J. Peron wrote: > 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. Christian, Thanks for the info. It sounds quite powerful. Does this system allow the checksum to be a digital signature instead? A potential customer has asked that no file be executed unless signed with their master key, to prove that the executable was issued by their central office. The kernel would check that the executable file had a digital signature signed by the central office - so even if you gained full write access to the directory, you would be unable to execute your malicious program unless you had compromised the signer's private key. Thanks again!