HOWTO: Use Fusion with a Guest Account for Improved Nonpersistance

Version 3

    Disclaimer: This is a personal document and is not official or endorsed by VMware. Feedback and suggestions are welcome.

    Note: This is

    very unsupported (since an important technique it depends on, manual linked cloning, is also very unsupported).

     

     

    Motivation and Use Case

    One use case for Fusion is where untrusted users need temporary access  to virtual machines, such as a grade school computer lab. This HOWTO  will show how to set up an environment that's relatively safe and  appropriate - guest users will not be able to make persistent changes to  the virtual machine, but login time will not be adversely affected.

     

    Another use case is if you want to quickly provide a sandbox - for  example, I might want to loan my laptop to a friend and allow them to  install any software in the guest(s), but leave the host alone.

     

     

    Difficulty Level and Requirements

    Very Advanced: You should be  familiar with editing .vmx files and be experienced with creating and  using virtual machines, and preferably other VMware products. You will  need administrator account because we will be editing system files. You  should be familiar with general OS X usage and security, as well as know  how to use the command line.

     

     

    This builds off the technique in

    HOWTO: Manual Linked Cloning in Fusion. You should read that first, understand the principles of what's going on, and be able to do it.

     

     

    You must be using Leopard, which introduced Guest accounts. You might be  able to script the equivalent in Tiger, but I'm not sure where to begin  looking for that.

     

     

    I assume good host security, i.e. unprivileged users cannot access stuff they're not supposed to.

     

     

    Background

    In an untrusted environment, one user must not be allowed to affect  others (e.g. student A should not be able to leave malware around to  impact student B). A less paranoid use case would be that you might want  to guarantee a fresh working environment. A Guest account in Leopard  will get us partway there - changes are discarded when the user logs  out. An administrator can modify the default user template, which allows  us to put arbitrary files in the Guest account.

     

    The problem with the naive approach of simply dumping a virtual machine  in the default user template is that virtual machines are large. Each  time a user account is created (which happens each time the Guest logs  in), the user account is copied. This isn't a problem for the default  set of files, but add in a multi-gigabyte virtual machine (or two, or  three...) and login times will be unacceptably long.

     

     

    We could keep the virtual machine in a shared location as described in

    A Beginner's Guide to VMware Fusion,  but this would violate the security motivation - if anyone can write to  the virtual machine, and the virtual machine is persistent, than they  can affect later users. Fusion requires virtual machines to be writable,  so you can't clear the write bits and still have the virtual machine  run.

     

     

    We can solve both problems by using a linked clone as described in

    HOWTO: Manual Linked Cloning in Fusion.  A nice property of a linked clone is that it starts off very small - on  the order of a few megabytes at most, as opposed to many gigabytes. Due  to the small size, the template will still copy quickly. At the same  time, a linked clone doesn't care if the parent is writable (and in fact  it's better if it's not), so we can keep the base disk read-only and  therefore safe.

     

     

    Limitations and Notes

    This is not

    a method to lock down Fusion or a virtual machine.  Users will still be able to create new virtual machines, bring in their  own, or copy out the one they're working with (though this last task  requires some Fusion knowledge).

     

    While this can be used to make a virtual machine that resets to a  known-good configuration, using a nonpersistent disk is a simpler  solution for non-malicious users. Note that a malicious user can  circumvent a nonpersistent disk if given full access to all the virtual  machine files, so a nonpersistent disk by itself is not sufficient for  all cases.

     

     

    These changes will affect not only the guest user, but any newly created user. This might or might not be a problem for you.

     

     

    Instructions

    Create the Virtual Machine

    Follow the instructions in the Prepare the Guest

    section of HOWTO: Manual Linked Cloning in Fusion

    .  If only the guest user will be using this virtual machine, you don't  need to sysprep it (if you choose not to, you may have to make sure the  MAC address remains constant). I will assume the shared virtual disk is  placed in /Users/Shared/. Unlike HOWTO: Manual Linked Cloning in Fusion

    ,  let's use absolute paths for this one (not strictly a requirement, but I  tend to like relative paths when dealing with my own files and absolute  paths when dealing with other users).

     

    Make sure that none of the .vmdk files

    or the folders containing  them (all the way up to /Users/Shared/) are writable. The .vmdk files  not being writable is obvious - you don't want a user modifying these  files, that would defeat the security point. A slightly less obvious  constraint is that the folders must not be writable - if they were, even  though users couldn't modify the .vmdk files themselves, they could  replace them with other files (thus effectively modifying them).

     

     

    Create a linked clone as in

    HOWTO: Manual Linked Cloning in Fusion and make sure it works as expected. Remember to take a snapshot before  powering on, and if you did power on, remove any uuid entries from the  .vmx file so the guest user isn't prompted about them.

     

     

    Copy to Default User Template

    Once you're happy with the virtual machine, we need to put it in the  default user template so that the guest user will see it. On Leopard,  the default user templates are located in /System/Library/User  Template/. Unfortunately, they're root owned, so even with sudo it's a  little bit of a pain to deal with (for example, you can't cd into them).  You can enable root access (I wouldn't recommend this) or just live  with it for the little while it takes to do this step (which is what I  did and will assume for the rest of this document). You might also want  to create a backup copy of the default user template.

     

    Open a terminal window and cd to /System/Library/ (I will assume you're  there for the rest of this document). We can't go further, since User  Template is root owned. At this point, every time we reach into the User  Template folder we'll need sudo. Lets first take a look around.  Assuming your default language is English (adjust appropriately if not),  the command would be

     

    sudo ls -lAF User\ Template/English.lproj/

     

    which on my system returns

     

    -rw-------   1 root  wheel    3 Jul 24  2007 .CFUserTextEncoding
    drwx------+  3 root  wheel  102 Mar 31  2008 Desktop/
    drwx------+  4 root  wheel  136 Dec 15 21:21 Documents/
    drwx------+  4 root  wheel  136 Dec 15 21:21 Downloads/
    drwx------+ 20 root  wheel  680 Mar 31  2008 Library/
    drwx------+  3 root  wheel  102 Mar 31  2008 Movies/
    drwx------+  3 root  wheel  102 Mar 31  2008 Music/
    drwx------+  4 root  wheel  136 Dec 15 20:26 Pictures/
    drwxr-xr-x+  4 root  wheel  136 Mar 31  2008 Public/
    drwxr-xr-x+  5 root  wheel  170 Dec 15 20:26 Sites/

     

    It's what you would expect a blank user template to look like. Anything  you copy in here will automatically be copied to a new user's account  (this is true not only of guest users, but any newly created user).

     

     

    Let's assume you want to put the virtual machine in the guest's  Documents directory (other good choices might be on the Desktop or just  in their home folder). If the prepared clone is located at  /Users/etung/Virtual Machines/Default.vmwarevm, the command would be:

     

    sudo cp -r /Users/etung/Default.vmwarevm User\ Template/English.lproj/Documents/

     

    If you log in as a guest now, you should see the virtual machine and the  login process should be fast (since the added virtual machine should  not have been very large).

     

     

    Copy Other Support Files

    We could stop here, but if you were to run the virtual machine in the  guest account, you'd see Fusion's first-run windows (since the guest has  not run Fusion before, and remember that when the guest logs out all  the guest's files are erased, so having run Fusion doesn't persist). We  can get around this by making Fusion think it's already been run once.  We need two preference files: com.vmware.fusion.plist and VMware  Fusion/preferences.

     

    com.vmware.fusion.plist

    com.vmware.fusion.plist is located in  /Users/${USER}/Library/Preferences/com.vmware.fusion.plist. If you've  run Fusion, it probably has a bunch of entries, but we're only  interested in the boolean VMWelcomeScreenViewed_2.0

    . If you have  the developer tools installed, you can make a copy and work on it using  Property List Editor (which will allow you to selectively keep other  entries you want, though I suggest getting rid of anything in the  favorites list); if not, you can use the following command to create a  dummy file:

    defaults write com.vmware.fusion-copy VMWelcomeScreenViewed_2.0 -bool yes

     

    Now copy this to the User Template folder (modify path as appropriate for your user):

     

    sudo cp /Users/etung/Library/Preferences/com.vmware.fusion-copy.plist User\ Template/English.lproj/Library/Preferences/com.vmware.fusion.plist

     

     

    preferences

    The preferences file is located in  /Users/${USER}/Library/Preferences/VMware Fusion/preferences. If you've  run Fusion, it probably has a bunch of entries, but we're only  interested in the value of pref.registrationViewed. You can create a  copy and edit it to your liking, or paste the following into a text file  (watch out for line endings, some browser/text editor combinations  mangle them. You can work around this by deleting the newline and typing  it yourself) - make sure to save it as a plain text file with no  extension.

    .encoding = "UTF-8"
    pref.registrationViewed = "TRUE"

     

    Now copy this to the User Template folder (modify path as appropriate for your user):

     

    sudo cp /Users/etung/Library/Preferences/VMware\ Fusion/preferences-copy User\ Template/English.lproj/Library/Preferences/VMware\ Fusion/preferences

     

     

    At this point, if you log into the guest and start Fusion, you should not see the first-run windows.

     

     

    Further Extensions

    You might want to further customize the default user template - for  example, you might be able to get the cloned virtual machine to  automatically start (look in com.apple.loginitems.plist, though I'm not  sure about syntax). You could add other virtual machines to the guest  account. You could copy over other parts of the support files (perhaps  populate the Virtual Machine Library).