Date: Fri, 4 Jul 2014 15:46:30 -0500 From: Nathan Dautenhahn <dautenh1@illinois.edu> To: George Neville-Neil <gnn@neville-neil.com> Cc: "hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: Kernel Privilege Separation Policy Message-ID: <20140704204630.GC16358@trypticon.cs.illinois.edu> In-Reply-To: <DF9FE077-093A-4251-B3A6-D67D51509602@neville-neil.com> References: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> <53B5ADBE.1020905@freebsd.org> <DF9FE077-093A-4251-B3A6-D67D51509602@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140704204630.GC16358>