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<[email protected]>
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
[email protected]
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
[email protected]
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
_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev
