File Permissions for Snapshots on Linux Host

[rkr002]

I have a question similar to http://communities.vmware.com/message/1000025

however the problem is some different.

VM Workstation is running on a Linux host, the guest is any system.

I have a VM machine which is used by two non-root users (only one user runs the VM at a time, of course).

I assigned the users to a group, and made this group the owner of the VM-machine dir and files,

I also set GID attribute for the dir, to have new files be created with the group as the owner.

All files have 'rw-rw----' and this works OK, the users can run the VM in turn - no problem.

However, when one of them makes a SNAPSHOT of the VM, the Workstation creates new files and sets their attribs to 'rw-------', so the GROUP is no longer able to access the snapshot files, resulting another user is unable to run VM.

I have a temporary solution to login as the root and restore the permissions to 'rw-rw----', however this is troublesome.

Why does Workstation set such strong 'rw-------' permissions for the new files it creates ?

Is there a way to avoid such "intervention" of the root ?

[ksc]

The reason is that "sharing" of VMs is a difficult behavior to define.

If you take a snapshot, do you truly intend that any other user have complete access to all the memory within the virtual machine? Some people might expect this (you), some don't ("security theater" researchers who would loudly publicize such a feature as a "guest compromise" security vulnerability - believe me, they've come up with worse). You may expect to only be sharing a logged-out desktop, and not the contents of kernel memory. And to share a snapshot, you really do have to share the full contents of kernel memory - which could include passwords you've typed in the past few days within that VM. Search for a research paper "Understanding Data Lifetimes" - it's quite sobering. Anyway - the security implications are quite difficult.

The Workstation design is to err on the side of caution, and always set a 0600 permission set (overriding umask even) when a file with guest memory is involved.

As to whether things will remain this way - you know the standard answer about not commenting. In this case it's particularly true - I'm working on a prototype (literally now, behind this web browser window) where permissions could be less restrictive. Even I have no idea when or if it would make it into a product - we may yet decide that the prototype represents an unacceptable lapse of security.

[rkr002]

Thanks for the detailed answer.

I wrote this question while being concentrated on my requirement, however I agree that the problem of sharing of a VM and the "guest security" really concerns many aspects and is not easy to decide and implement.

What concerns the kernel memory, I always make snapshots when the VM-guest is down, so the problem of kernel memory does not occur, but of course this is only my case and it's not any general solution.

In fact, the most obvious way to have a shared VM is to share it at desktop level and use builtin guest-OS functions, like multisession support in Windows or VNC sessions in Linux (which I currently use in both systems and it works fine; the Workstation behaves like a VM Server in this case ).

And the physical access to the VM and its files should be reserved for one priviledged user only (a VM "server" admin).

[birdie]

You can create a wrapper for running vmware which will call original vmware process and then set proper file permissions after vmware has exited.

Something like (after renaming /usr/bin/vmware to vmware.original):

#! /bin/sh

vmware.original

cd /path/to/vm

chmod 660 .vm

where =* since Jive forum drive me mad.

[rkr002]

Thanks for this suggestion, really could be helpful.

I'v forgotten to write that I tried this some time ago, however I could not find a good way to avoid the terminal window appearing, because this script must "wait" until VM Workstation ends, and if the terminal window is accidentaly closed, the whole procedure fails.

There are also other nuisances:

-> if you close the terminal window, the VM window also closes (nothing is lost, because then I can "connect" to the VM manually opening Workstation, but the script already have gone)

-> I checked it does not matter if "vmware" process is called in background or not

-> eventual other background processes (or scripts) "waiting" for Workstation would rather complicate the things

-> "chmod 660" could be also in the script before the VM starts, but this also won't help, because changing files' attribs can only be done by the user who made the last snapshot, so another user running this script is unable to do this

In fact, neither way is easier than manually restoring the file attribs (event. using a script, but manually started).

I think, I could rather use a script-wrapper which detects files having 'rw-------', tries to restore attribs and if it fails - ask the user for intervention, or - if all files are OK - starts VM in normal way.

OK, I aggree this is in fact a problem concerning Linux, not Workstation, however if you had any suggestion how to solve it in elegant way, I would be thankful.

Anyway, don't bother too much about this problem, it's not worth spending so much time.

I should rather ask Linux people about that

[rkr002]

OK, I've thought again about the subject and ... really, there are some solutions.

I can use a copy of "chmod" program as "chmod-vm", owned by root and SUIDed,

or (probably more safe) allow to run this copy of chmod program by using "sudo".

Now I can put

./chmod-vm 660 .vm

or sudo ./chmod-vm 660 .vm

at the begin of the script-wrapper, and REALLY all the problems are solved!

Of course, the ./chmod-vm program is dangerous, so the solution can only be applied in a trusted environments, having trusted users whom we allow sudo, event. having innocent name of the copy of chmod, outside any path, etc. etc. ...