[vbox-dev] how to shutdown VBox open APIs?

[Pau Garcia i Quiles]

Hello,

What about signing the configuration (.vbox) file?

To read (i. e. to run the VM), VBox would check if the signature is fine.

To modify the VM configuration (i. e. add or remove a hard disk, DVD,
attach a different DVD image, change network from NAT to bridget,
etc), a password or key would be required.

To avoid breaking the API too much, a "key" parameter could be added
to IVirtualBox::OpenSession/OpenRemoteSession. If no key is required,
just set key = NULL.

That would at least prevent third parties from changing the
configuration. It would be very useful for me, for instance, because
that way I can distribute a "certified my <my company>" VM which I
know works perfectly fine. If user tries to tamper it (for instance,
booting it directly from VirtualBox instead of my application), it
won't even boot.

Then there is the problem of disk access. Some kind of protection
would be required for .vdi files too. A password when
opening/attaching the medium would be enough to prevent some user from
taking the .vdi files from my VM folder and attaching them to a VM he
has created from scratch.

Of course there is another problem: if the password/private key (yes,
I'm thinking in public keys for the .vbox signatures) is in memory, it
can be read. Some kind of obfuscation is required but I'd say that is
something to leave to the OEMs developing applications with VBox APIs.

An idea I had a few months ago was distributing some kind of
actually-virtualized portable applications. The fundaments would be
VirtualBox to virtualize the application, a small executable and a big
file which would contain the .vdi, .iso and .vbox files (a filesystem
in a file, in Unix lingo). When ran, the small executable would mount
the filesystem-in-a-file, start VBox (or even install it, if it's not
installed yet), start the VM contained in that filesystem-in-a-file
and star the application pointed by the small executable. It's akin to
what Thinstall does, but will real virtualization. I even had a
prototype for Windows using C# and Interop for VBox COM. The main
problem is finding something like FUSE/mount which performs well on
Windows (I tried Dokan and a commercial alternative, performance for
both of them was horrible). That's a case where "untamperable VMs"
like Huihong proposed would be very useful.

</braindump> :-)


2010/12/9 Achim Hasenmüller <achim.hasenmueller at oracle.com>
>
> On Dec 9, 2010, at 19:46 , Huihong Luo wrote:
>
> Achim,
>
> will look into that, at least some control, maybe check hash values of the binary of the calling process, so it prevents a user from renaming its own exe to VBoxManage.exe, for example
>
>
> You can never protect anything when the user has administrator rights in Windows. So my approach was based on the assumptions that the whitelisted binaries would live in directories the user does not have write access to.
> Achim
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> http://vbox.innotek.de/mailman/listinfo/vbox-dev
>



--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)