From owner-freebsd-stable@FreeBSD.ORG Thu Apr 10 15:19:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 804681065670; Thu, 10 Apr 2008 15:19:36 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB418FC1E; Thu, 10 Apr 2008 15:19:36 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 8196B2E1; Thu, 10 Apr 2008 10:03:03 -0500 (CDT) Date: Thu, 10 Apr 2008 10:03:03 -0500 From: "Christian S.J. Peron" To: Kris Kennaway Message-ID: <20080410150303.GA86000@sub.vaned.net> References: <47F3DA07.4020209@forrie.com> <20080402203859.GB80314@slackbox.xs4all.nl> <20080403164108.GA12190@slackbox.xs4all.nl> <20080404165541.GA675@slackbox.xs4all.nl> <47FE26BC.3000305@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47FE26BC.3000305@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Ivan Voras , Peter Wemm Subject: Re: Digitally Signed Binaries w/ Kernel support, etc. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2008 15:19:36 -0000 On Thu, Apr 10, 2008 at 04:39:56PM +0200, Kris Kennaway wrote: [..] > > csjp@ had a mac_chkexec module that looks like it was never committed. > > http://groups.google.com/group/mailing.freebsd.hackers/msg/074eec7def84c52b > > Shouldn't be hard to update it. > Just a few notes: - This isn't really "binary signing" per se, I associate a cryptographic checksum with a shared object, executable, shell script etc... Then if you try to mmap the shared object into the address space, or execute the executable object (after it was back-doored with malicious code), it will deny it (assuming the system is in "enforce" and not in "learning" mode). Also, new binaries (ones without checksums associated with them) would not be permitted to execute. True binary signing basically requires that the signature is part of the executable format. for example: embedding a certificate in the ELF structure. This would allow us to distribute binaries across systems. In my model, we are using extended attributes, which offers security for the local system only (but still useful if the intent is to allow certain users to upload new binaries, and protect against exploits or backdoored binaries). - Mathew Dodd and I started working on a "bignum" library for the kernel so we could perform the arbitrary precision arithmetic required for various PKC operations to implement proper "signing", and for the most part it worked, but I think there were some edge cases where there are problems. (Since there is some interest here, I could be convinced to pickup the project again). - I have not committed this because I do not want to import the userspace utilities required to manage the checksums. In retrospect, I should have stored the checksums in the MAC label. I intend to correct this, and it's likely I could add it to base once this is done. The code listed in the link above is not likely to compile due to some MAC entry point renaming that was completed. However I should be able to fix this pretty quickly and send a follow up email here for anyone who is interested in experimenting. http://people.freebsd.org/~csjp/mac/trustedexec.png Describes it's operation at a high level.