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

[Klaus Espenlaub]

On 09.12.2010 20:53, Pau Garcia i Quiles wrote:
> Hello,
>
> What about signing the configuration (.vbox) file?

What about doing a design first, and then figure out if cryptography is 
the solution?

In the long run such extremely special solutions should become extension 
packs, since such tailoring is exactly the opposite of what the majority 
of the user base wants.

We're not there yet, but I'd encourage you to think along such lines, 
instead of requiring us to introduce a whole collection of optional 
parameters which no one but you will ever use. We're open for 
suggestions how to make extension packs even more flexible and powerful.

> 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.

This isn't thought out - how do you want to protect a file the user has 
full control over? If the user has the VM config, then the password must 
be somewhere.

Obfuscation is not a solution, it's selling snake oil.

> 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>  :-)

Surely lots of ideas, but the black boxes are far from implementable in 
the current form. Files cannot magically protect themselves, so that's 
actually the first problem to solve.

So far the only solutions in this I'm aware of are not giving the user 
the file, but have it in a safe place...

Before there's a design which covers the data management in general I 
see very little point in thinking about the necessary API and/or 
extension pack details.

Klaus

>
>
> 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)
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> http://vbox.innotek.de/mailman/listinfo/vbox-dev


-- 
Oracle <http://www.oracle.com>
Dr. Klaus Espenlaub | Principal Software Engineer
Phone: +49 7151 60405 205 <tel:+49715160405205>
Oracle VirtualBox

ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to
developing practices and products that help protect the environment