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
--- On Thu, 12/9/10, Achim Hasenmüller <[email protected]> wrote: From: Achim Hasenmüller <[email protected]> Subject: Re: [vbox-dev] how to shutdown VBox open APIs? To: "Huihong Luo" <[email protected]> Cc: [email protected] Date: Thursday, December 9, 2010, 10:29 AM Huihong, the COM API access control is a great idea, I've been pondering about this for years. If you find a way to do this (basically you have to whitelist the process when IVirtualBox gets instantiated), it would be awesome. Regarding further protection, I'm not a fan. It's a rat race. Some customer has created a setup on Windows hosts where VBox runs as a different user and apparently they were able to circumvent UAC by writing their own runas service. I don't have more details. Achim On Dec 9, 2010, at 19:19 , Huihong Luo wrote: We got more and more users to request how to deliver a vm whose configuration cannot be modified in any way. VBox is so powerful in its APIs, which is a very good feature compared to other vm software. However, this feature makes it very difficult to prevent people from chaning the vm settings, etc. Any thoughts on this? VBox uses across process COM communications, so need a way to only allow internal components to use those APIs, but disallow external programs to use it. Even this is done, a hacker can easily hook a DLL's exports, and change the code. For example, even if a VDI disk is encrypted, I can easily hook VBoxDDU.dll to dump its raw content, and bypass the encryption.
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
