From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 20:46:35 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C173761; Fri, 4 Jul 2014 20:46:35 +0000 (UTC) Received: from trypticon.cs.illinois.edu (trypticon.cs.illinois.edu [128.174.237.181]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18A03204C; Fri, 4 Jul 2014 20:46:34 +0000 (UTC) Received: from trypticon.cs.illinois.edu (localhost [127.0.0.1]) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Debian-2.1ubuntu2) with ESMTP id s64KkWSe025606; Fri, 4 Jul 2014 15:46:32 -0500 Received: (from dautenh1@localhost) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Submit) id s64KkUBm025576; Fri, 4 Jul 2014 15:46:30 -0500 Date: Fri, 4 Jul 2014 15:46:30 -0500 From: Nathan Dautenhahn To: George Neville-Neil Subject: Re: Kernel Privilege Separation Policy Message-ID: <20140704204630.GC16358@trypticon.cs.illinois.edu> References: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> <53B5ADBE.1020905@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:46:35 -0000 On Fri, Jul 04, 2014 at 10:27:57AM -0400, George Neville-Neil wrote: > On 3 Jul 2014, at 15:23, Julian Elischer wrote: > > >On 7/2/14, 10:52 PM, Dautenhahn, Nathan Daniel wrote: > >>Hi All- > >> > >>I am a graduate student at UIUC and am currently working on a > >>system that > >>isolates the MMU from the rest of the FreeBSD kernel. For the > >>purpose of > >>enabling privilege separtion within the kernel. > >> > >> > >[...] > > > >it does sound interesting.. I think the dearth of answers is that > >everyone is waiting for someone-else to answer, because the topic > >sounds a bit intimidating, > > I also think we'd be interested in seeing the code itself, and what > APIs it exposes. > That would probably focus thinking on what can be done with it. Hi George- I will start working on getting the code available for view on a github repository. It is currently in a research prototype state, but moving it into a more production level is a goal. The base system effectively splits the kernel into two privilege levels: 1) a very small component that mediates access to the MMU to enforce system wide memory access policies, and 2) the lower privilege part of the kernel. The initial set of policies that I'm investigating are write protect policies within the kernel itself (we can do read protect too). In other words place specific data structures into the secure region (thus protected from the rest of the kernel), and then mediate write access through a *write_secure_data()* interface by some to be determined policy. Effectively the type of interface I have is: - Some data structure allocated to write protected pages - A mediation policy for that data structure -- set of checks the write must pass - A write_ function for such data structures I am not well versed in how to translate this to the "interface" you asked for, but the basic idea is to apply some type of access policy to critical data structures to improve the security of the system. Another example benefit or application of such a *write_protect* mechanism is that even if the *write_secure_data* function does not include an access control policy, the data structures being protected will not be subject to memory corruption in the insecure kernel. For example, the UMA allocator vulnerability mentioned on Phrack [1] could be defended by write_protecting the critical allocator metadata (slab header). I appreciate any ideas and even questions. I find that these help me to understand the system with greater clarity. Thanks, ::nathan:: [1] http://phrack.org/issues/66/8.html > > Certainly there is the possibility of walling off drivers during development > but there must be other, more interesting, applications. > > Best, George