<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Huihong,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Achim</div><div><br><div><div>On Dec 9, 2010, at 19:19 , Huihong Luo wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><table cellspacing="0" cellpadding="0" border="0" style="position: static; z-index: auto; "><tbody><tr><td valign="top" style="font: inherit;"><div>We got more and more users to request how to deliver a vm whose configuration cannot be modified in any way.</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>For example, even if a VDI disk is encrypted, I can easily hook VBoxDDU.dll to dump its raw content, and bypass the encryption.</div>
<div> </div>
<div> </div></td></tr></tbody></table></blockquote></div></div></body></html>