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.
I also tried locking down COM to a specific user however it was extremely unreliable on windows XP (See http://www.virtualbox.org/ticket/8426) I think I'll be making two new frontends: VBoxBGUI -- With GUI (Don't know if I'm going with SDL) VBoxBHeadless -- Same as above with no GUI. I don't know how far I'll go before giving up, but I really appreciate it the help/future help? Thanks a lot! This is all starting to sound like a great challenge! On Tue, May 10, 2011 at 2:46 PM, Klaus Espenlaub <[email protected] > wrote: > On 10.05.2011 18:03, Ribhi Kamal wrote: > >> Thanks, >> I think that in my case I will have two binaries and each is responsible >> of starting a specific type of virtual machine. Everything will be hard >> coded, the network interfaces, the ISO location, guest controllers... etc >> > > In such a case VBoxBFE might be a reasonable starting point. With a big > question mark. > > 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. > > Additionally it's non-trivial to replace libSDL with something else. > > > I'm worried about starting two virtual machines at the same time, is >> there going to be some conflicts when calling the kernel driver >> (vboxdrv) ? I guess my question is, is there some danger from starting >> two VMs using VBoxBFE (without COM)? >> > > 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). > > > Finally, does anyone know if Oracle has something similar to what I'm >> doing -- No COM/XML? Money is not a problem (not yet anyway). >> > > No customer has asked for no management so far if my memory doesn't fool > me. Generally they want more, preferably impossible management conditions :) > > Thanks again >> >> On Tue, May 10, 2011 at 9:10 AM, Alexey Eromenko <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Tue, May 10, 2011 at 3:34 PM, Ribhi Kamal <[email protected] >> <mailto:[email protected]>> wrote: >> > The problem with COM (XPCOM too?) is that its very hard to lock >> down. >> > Especially when %50+ of people run everything with admin privs. >> So I'm >> > > 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. > > > > trying to reduce the attack vectors that can be done from the >> host OS on the >> > virtualvbox installation it self. >> > >> > Can you please explain a bit about the "VM synchronization point" >> issue? >> >> "VM synchronization point" is a single host management layer. >> > > The host part is done in the driver. > > VBoxSVC only cares about a single user. > > > The biggest difference between Qemu and VirtualBox engines, from >> programmer's point of view, is that if you write any program for Qemu, >> you must reimplement management layer yourself. >> > > That's correct again. > > > VirtualBox already provides single-host management layer (via >> VBoxSVC). Registered VMs. Each VM remembers it's parameters, such as >> RAM, HDDs assigned, Network adapters (along with MAC addresses), >> etc... >> > > Right. VirtualBox has so many options these days that it's simply not > efficient to use a command-line based approach. > > The (XP)COM based API serves as a big sanity checker and reduces many error > sources with creating and running VMs. > > Klaus > > >> -- >> -Alexey Eromenko "Technologov" >> >> _______________________________________________ >> vbox-dev mailing list >> [email protected] <mailto:[email protected]> >> >> http://vbox.innotek.de/mailman/listinfo/vbox-dev >> >> >> >> >> -- >> -- Ribhi >> > > _______________________________________________ > vbox-dev mailing list > [email protected] > http://vbox.innotek.de/mailman/listinfo/vbox-dev > -- -- Ribhi
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
