Date: Wed, 2 Jul 2014 14:52:40 +0000 From: "Dautenhahn, Nathan Daniel" <dautenh1@illinois.edu> To: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Kernel Privilege Separation Policy Message-ID: <E007DF84-0303-4AB7-AE69-9E8F79CF01AA@illinois.edu>
next in thread | raw e-mail | index | archive | help
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.
- This code is approximately 3k lines.
- This base system also provides kernel code integrity (write protection =
in
memory) as one of its base properties.
- This is somewhat follow up work on previous publications VirtualGhost
(ASPLOS '14) and KCoFI (IEEE SP '14). The new system uses similar MMU
policies to create the isolation within the kernel.
Controlling the MMU enables read/write protection policies (for memory page=
s)
to be enforced within the kernel itself.
I am interested in thoughts from the community on how to best use an
intra-kernel isolation and mediation mechanism?
One example policy or use of this mechanism would be to place critical func=
tion
pointers into a write protected region of memory and apply a policy where
function pointers (such as a system call function pointer) are only allowed=
to
be set once (a write-once policy).
Some initial ideas I have include:
- Protecting against common root kit behaviors such as system call hookin=
g,
character device hooking (protect function pointers), DKOM (modifying
process lists to hide data), kernel object hooking, etc.
- Protecting capabilty enforcement
- Mandatory Access Control Mechanism enforcement
- Auditing mechansims (to ensure integrity of audit logs)
Does anyone have insight into these or other important uses of this type of
system? What would be a "killer app" type use in the kernel?
I can be available on IRC if a real time discussion seems like a better pla=
ce
for discussion.
Thanks,
::nathan::
[I have posted this to both freebsd-hackers and freebsd-security lists =97 =
I wasn=92t sure what was best]=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E007DF84-0303-4AB7-AE69-9E8F79CF01AA>