First, read
this. I wasnt able to use the resource kit tools because Macrosh@ft wont allow you to redistribute their tools. So, we instead bought a tool that offered an OEM license. If you dont know what ACE is, its vmware's option pack for VMware Workstation. Its basically a bunch of security features and packaging options, meaning, you can build vm and then package it up and install it on another system. I wanted to use it because I wanted to make sure the server could not be copied and run somewhere else by anyone except the people I choose and authorize.
One of the features in an ACE policy is that allows you to run a script or executable instead of enter a password when the vm is started. The VMware ACE Player, interestingly enough, will accept a string from STDOUT of this script or exe in order to attempt the decryption of the encrytion key thats used to read the vmdk files as the vm runs. Using
FireDaemon and the FireDaemon features of Pre-Post Service commands, I was able to use vmrun.exe stop command to shut down the vm when the host system is rebooted. I also made lanmanworkstation a service that the Firedaemon service depends on. This way, the vm is not started until the network is full up on the host system...other people have mentioned using this technique and it seemed like a good one.
The executeable, written in VC++ STL, accepts two args, a meaningful 9 digit number and a secret. If either of these args fail a number of tests performed on them, the exe quietly exits. If the args pass, a SHA512 hash (using
openssl) is performed and a 64 character string is printed out to STDOUT. Its this string that the vmplayer.exe uses to encrypt/decrypt the AES keys that encrypt/decrypt the vmdk's when the vm starts.
These files, the exe and the openssl libs (dll's) and the VC manifest and their dll's and any other script and stuff you want to use in the Firedaemon service configuration, reside in the "ACE Resources" directory, under the parent directory of the vm Master.
Also, i got snagged by this: each time a package is built, the packager drops an ace.sig file into the "ACE Resources" directory of the package it generates. Make sure this ace.sig file doesnt get copied back into the Master "ACE Resources" directory. If it does, all the packages that you make will have this invalid file in there. Its easy to get into this situation when you delete the files in that directory in order to make a test package that may be updated with a policy update package, which
would contain the authentication module and scripts. VMware should fix this by checking for this file and deleting it from within the Master's dir structure each time the packager runs, but it doesn't at this time. Anyhow, there is a policy option called Resource Signing that does check this file, and if its set to check it, which it is by default, the activation of the package (or policy update) will fail.
There was one more terribly annoying thing with setting up the service. When I attempted to shutdown or reboot the host system (unforced), the vmplayer.exe would abort the shutdown/reboot operation and display a modal dialog box that says "virtual machine is in use." I got around this by using
AutoIT, a freeware application that allows you to create a simple script to operate windows and applications. So far its been a breeze and a very sensible and intuitive scripting language. Good docs help a lot too. Anyhow, this script ran as a Firedaemon pre-service and sits there waiting for that stupid dialog box to activate. It checks for this window every 250ms. Then, when the shutdown sequence starts, it gets rid of the dialog box and reboots the host system. Pretty slick.
Its too bad vmware says they wont support ACE vm's anytime soon on ESX or VMware Server. It would be pretty simple to get this working and I think that vm volumes that remain encrypted on-disk at all times solves a very difficult security challenge in operating system virtualization. no longer can someone make a copy of your entire filesystem and mount it somewhere else.
