Unfortunately, the virtual machines are targeted at personal computers of corporate users.. so these users can do anything, go to safe mode, change admin password from a live CD... you name it. So the protection is done at run time with signature checking and a filesystem filter driver. <br>
<br>I also tried locking down COM to a specific user however it was extremely unreliable on windows XP (See <a href="http://www.virtualbox.org/ticket/8426">http://www.virtualbox.org/ticket/8426</a>)<br><br>I think I'll be making two new frontends:<br>
VBoxBGUI -- With GUI (Don't know if I'm going with SDL)<br>VBoxBHeadless -- Same as above with no GUI.<br><br>I don't know how far I'll go before giving up, but I really appreciate it the help/future help?<br>
<br>Thanks a lot! This is all starting to sound like a great challenge!<br><br><div class="gmail_quote">On Tue, May 10, 2011 at 2:46 PM, Klaus Espenlaub <span dir="ltr"><<a href="mailto:klaus.espenlaub@oracle.com">klaus.espenlaub@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 10.05.2011 18:03, Ribhi Kamal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
I think that in my case I will have two binaries and each is responsible<br>
of starting a specific type of virtual machine. Everything will be hard<br>
coded, the network interfaces, the ISO location, guest controllers... etc<br>
</blockquote>
<br></div>
In such a case VBoxBFE might be a reasonable starting point. With a big question mark.<br>
<br>
Without the COM API you have to implement many features yourselves. VBoxBFE doesn't support snapshots and other slightly more complicated features. Also, since it's been unmaintained for many years it's way beyond the feature support of the other VM frontends (different storage controller support, multiple DVD drives, network boot, bridged networking, different network card models, leave alone dynamic configuration changes at VM runtime). All implementable, but LOTS of work and once you're done you probably introduced something which is worse than (XP)COM.<br>
<br>
Additionally it's non-trivial to replace libSDL with something else.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm worried about starting two virtual machines at the same time, is<br>
there going to be some conflicts when calling the kernel driver<br>
(vboxdrv) ? I guess my question is, is there some danger from starting<br>
two VMs using VBoxBFE (without COM)?<br>
</blockquote>
<br></div>
No. The kernel driver has all necessary synchronization. In a normal multi-user setup there is also no coordination between different VBoxSVC instances (which only care about one user).<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Finally, does anyone know if Oracle has something similar to what I'm<br>
doing -- No COM/XML? Money is not a problem (not yet anyway).<br>
</blockquote>
<br></div>
No customer has asked for no management so far if my memory doesn't fool me. Generally they want more, preferably impossible management conditions :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Thanks again<br>
<br>
On Tue, May 10, 2011 at 9:10 AM, Alexey Eromenko <<a href="mailto:al4321@gmail.com" target="_blank">al4321@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:al4321@gmail.com" target="_blank">al4321@gmail.com</a>>> wrote:<br>
<br>
On Tue, May 10, 2011 at 3:34 PM, Ribhi Kamal <<a href="mailto:rbhkamal@gmail.com" target="_blank">rbhkamal@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:rbhkamal@gmail.com" target="_blank">rbhkamal@gmail.com</a>>> wrote:<br>
> The problem with COM (XPCOM too?) is that its very hard to lock down.<br>
> Especially when %50+ of people run everything with admin privs.<br>
So I'm<br>
</div></blockquote>
<br>
Well, if you have so many people running things as admin then I would think VirtualBox is the least of your worries. I would consider it the primary goal to get people off the admin account, and use their own. Which would probably solve most of the lock down problems already.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> trying to reduce the attack vectors that can be done from the<br>
host OS on the<br>
> virtualvbox installation it self.<br>
><br>
> Can you please explain a bit about the "VM synchronization point"<br>
issue?<br>
<br>
"VM synchronization point" is a single host management layer.<br>
</blockquote>
<br></div>
The host part is done in the driver.<br>
<br>
VBoxSVC only cares about a single user.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The biggest difference between Qemu and VirtualBox engines, from<br>
programmer's point of view, is that if you write any program for Qemu,<br>
you must reimplement management layer yourself.<br>
</blockquote>
<br></div>
That's correct again.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
VirtualBox already provides single-host management layer (via<br>
VBoxSVC). Registered VMs. Each VM remembers it's parameters, such as<br>
RAM, HDDs assigned, Network adapters (along with MAC addresses),<br>
etc...<br>
</blockquote>
<br></div>
Right. VirtualBox has so many options these days that it's simply not efficient to use a command-line based approach.<br>
<br>
The (XP)COM based API serves as a big sanity checker and reduces many error sources with creating and running VMs.<br>
<br>
Klaus<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
--<br>
-Alexey Eromenko "Technologov"<br>
<br>
_______________________________________________<br>
vbox-dev mailing list<br></div>
<a href="mailto:vbox-dev@virtualbox.org" target="_blank">vbox-dev@virtualbox.org</a> <mailto:<a href="mailto:vbox-dev@virtualbox.org" target="_blank">vbox-dev@virtualbox.org</a>><div class="im"><br>
<a href="http://vbox.innotek.de/mailman/listinfo/vbox-dev" target="_blank">http://vbox.innotek.de/mailman/listinfo/vbox-dev</a><br>
<br>
<br>
<br>
<br>
--<br>
-- Ribhi<br>
</div></blockquote><div><div></div><div class="h5">
<br>
_______________________________________________<br>
vbox-dev mailing list<br>
<a href="mailto:vbox-dev@virtualbox.org" target="_blank">vbox-dev@virtualbox.org</a><br>
<a href="http://vbox.innotek.de/mailman/listinfo/vbox-dev" target="_blank">http://vbox.innotek.de/mailman/listinfo/vbox-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- Ribhi<br>