Kernel Privilege Separation Policy

[Dautenhahn, Nathan Daniel]

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 pages)
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 function
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 hooking,
    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 place
for discussion.

Thanks,
::nathan::

[I have posted this to both freebsd-hackers and freebsd-security lists — I wasn’t sure what was best]