[vbox-dev] Whitelisting vmexit activity

panda23 at hush.ai panda23 at hush.ai
Sun Dec 18 20:31:52 GMT 2011

I'm interested in making vbox more secure for sandboxing untrusted
compute-bound code.  I want to make it something like linux's seccomp,
so that the guest OS sends a signal to the VMM, probably by a
crafted vmexit event, indicating that any subsequent vmexit results in
the guest being shut down unless

  1) it's one of the "innocuous" vmexits which results in jumps to the
     ResumeExecution label in the *R0RunGuestCode functions in
  2) it's an event which can result from pure computation of the type
     "seccomp" is intended to allow (i.e., no attempt to access system
     resources) (I could use some help defining this whitelist.)

  3) it results from exercising any communication channels that the
     guest OS had estabilshed prior to sending the vmexit event.

The next step for me would be to learn to use the vbox
facilities to flesh out a whitelist covering scenarios (2) and (3). 
I can do that, I will put a new branch at the top of the huge switches
on exitReason in the *R0RunGuestCode functions, testing for the
vmexit event.  That branch will set a "seccomp" flag which will turn
the whitelist of vmexit events allowing scenarios (2) and (3).  It
probably also turn off pVM->hwaccm.s.fTRPPatchingAllowed as well. 
prior to the exitReason switch will be the whitelist code, which will
execute if the "seccomp" flag is set, and will kill the guest if the
vmexit event isn't on the whitelist.

This plan is based on studying the vbox source code for a bit less
a day, and may well be wrongheaded.  If you can shoot it down or point
out any likely pitfalls (especially security flaws), you'll be doing
a big favor. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20111218/894ff115/attachment.html>

More information about the vbox-dev mailing list