---+ BRIEF: What is the most secure way to run a GUI app in a VirtualBox guest from the host?
VBoxManage guestcontrol --username U run ...
- for an account that has no password
- which may require gpedit to allow
VBoxManage guestcontrol --username U --password P run ...
VBoxManage guestcontrol --username U --passwordfile PF run ...
or ssh (what network mode: NAT, ...)
---+ DETAIL
I have just started using VirtualBox, after past experience with VMWare, Parallels, Xen - heck, I worked on VMX aka VT before it was released. Overall, I am familiar with virtualization, but not so much with the incantations necessary to configure the software.
Host: MacOS Sierra
Guest: Windows 10 Pro (Microsoft's appliance, WinDev1612Sys)
I want to use this virtual machine for two purposes: (1) to run an old Windows GUI app (FrameMaker). (2) to run Windows Outlook, when Outlook for MacOS isn't good enough. Also (3), some Windows app development / portability testing.
Not only do I want to run the Windows GUI app (FrameMaker) interactively, but I also want to script it. I do that using FrameMaker's built-in ExtendScript, invoked from MacOS via VBoxManage guestcontrol run ...
(In case anyone cares, I switched from Parallels because I could not get prlctl to pass command line arguments, not even to specify a .BAT script for command.exe to run; and the old trick of editing the .app bundles created by Parallels Tools no longer worked - any attempt to edit the bundle contents, e.g. AppParam.pva, resulted in the bundle being deleted. Probably a security policy. I wasted far too much time trying to get Parallels to run parameterized automation scripts; whereas Virtual guestcontrol ran as soon as I tried it. Makes up for VirtualBox's seamless not being as nice as Parallels coherent mode.)
OK, so now I have something working. I can run scripts on MacOS that invoke GUI apps, and other scripts on the Windows guest. Great!
But...
---++ ps can see command line options like --password and --passwordfile
VBoxManage guestcontrol --username U --password P run ... is scary because the command line options are visible to any user running ps alxwww on MacOS. Any such user can see the password.
Similarly for VBoxManage guestcontrol --username U --passwordfile PF run ... Any such user can see the --passwordfile option - and, as far as I can tell, any such user can execute the same command. I.e. it is as good/bad as seeing the --password. (If guestcontrol run were somehow restricted to only allow such access if the host and guest usernames were the same, it might be more secure - but AFAICT, that is not supported.)
---++ passwordless guest account is scary
Nothing is visible to ps if the guest account has no password - but that scares me. Again, it appears that any host user, including anyone who is not me, can access the passwordless guest account. (Again, guestcontrol restrictions that host and guest user names match for passwordless operation might be more secure - but, still, not having a password is scary. Imagine if I configured bridged networking and my Mac was not behind a NAT (but then I am probably screwed anyway).
---++ Don't allow other users on my Mac
Now, I don't normally allow users other than me to use my Mac. But... I might, if I naively trusted OS user process security, and I forgot about an old installation of VirtualBox. The problem is that VirtualBox guestcontrol has a security perimeter than expands to include all host user IDs
---++ Lock VirtualBox down so that only I can use it
Possibly I could change file permissions so that only I can run VirtualBox installation tools. Also device special files, if VirtualBox installs Mac drivers. But furthermore... I happen to know that if VirtualBox is using Intel VMX / VT hardware virtualization hardware, it might be trapping things that MacOS filesystem permissions do not control.
(BTW, this is the security exposure that one gets from requiring the hypervisor run inside the kernel, from not permitting user level hypervisors. Layered VMs, guys!!!! (We'll only get there after another generation of virtual machine security break-ins.))
But I don't yet know VirtualBox well enough to do this. And a quick look seems to show no indication that VirtualBox was designed to make this easy. (Please tell me otherwise.)
---+ Passwords, not on the command line
If we have to pass a password to the guest, it would be best if it were not on the command line.
I seem to recall that ssh at one time had a --password command line option. Obviously insecure. Modern ssh does not seem to have such an option. Possibly my memory is wrong. But certainly there are folks who want to put the password on the command line, e.g, the sshpass package in Ubuntu (sshpass -p 'YourPassword' ssh - user@host https://unix.stackexchange.com/questions/38737/ssh-login-with-clear-text-password-as-a-parameter)
ssh avoids the need to have the password on the command line by prompting for the password - not visible from ps. Or by having public / private keyfiles (but that is only as good as the filesystem permissions (especially if public and private keys are not separated). Or by using ssh-agent.
I would feel better about VBoxManage guestcontrol if it used something like this.
Heck, I would feel better about guestcontrol --passwordfile if passwordfile were on the host filesystem, not the guest. Not good to have a password in a file, but better than on the command line, and equivalent to keyfiles if kept together and not separated. I am reasonably certain that I can make a file readable by me only in MacOS. ;-}
Hmm... I wonder if there's a mistake in the VBoxManage guestcontrol manpage - if --passwordfile is a host file, rather than a guest file? That would make more sense, and would explain why I have not been able to get --passwordfile guestfile to work.
That's my best hope.
---+ VirtualBox API
If VBoxManage guestcontrol can only pass passwords in a form visible from the command line, perhaps I could write my own script?
Surely somebody has alreadsy done this, if necessary. (I hope it is not necessary.)
---+ Why not ssh between guest and host?
All else failing, I could run an ssh server in the guest, and ssh in. ssh, after all, does a fairly good job of hiding passwords and other authentication tokens from ps, etc,
(I would prefer to use VBoxManage guestcontrol. Less to set up, less to misconfigure. But ssh is pretty standard.)
If I wanted to run ssh, how should VirtualBox's network be configured?
Host-only might be most secure - but that would not allow me to use Outlook in the guest without more crap.
I like running the guest behind VirtualBox NAT (and furthermore the Mac is probably also behind one or more layers of NAT, at home and work).
But if the guest is behind VirtualBox NAT, then ssh from host to guest would be blocked. So I would have to port forward. But I probably do not want to forward requests from the outside world, only from the local host.
It looks like
VBoxManage modifyvm ...
[--natpf<1-N> [<rulename>],
tcp|udp,
[<hostip>],<hostport>,
[<guestip>],<guestport>]
might do the trick.
The manpage example says
VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,127.0.0.1,2222,,22"
to forward all TCP traffic from localhost 2222 to the guest on port 22.
Does this seem right?
Testing shows that this works - but testing does not show the absence of a security problem.
Really what I want is a combination of hostonly for traffic coming in to guest originating from host, and NAT for outgoing.
(Hmm... on other VMs like Parallels, the problem was that ssh workedm but ssh could not start a GUI app. Haven't tested that on VirtualBox yet.)
---+ CONCLUSION
So, what's the best way?
I would hope that somebody has already figured this out.
I can set up NAT and ssh, assuming that GUI apps work.
But I would prefer it if guestcontrol was secure. Even if just a doc bug, with --passwordfile being a host file rather than a guest file.
Or perhaps I should not worry about hiding stuff from ps. Many folks seem not to care. But I care.