Hyper-V: A new breed of SID

If you already know what tokens, SIDs and DACLs are, skip ahead and go directly to the first image below.

Ever since Windows NT, the basic principle of Windows security, (i.e. Discretionary Access Control) uses SID and ACL (access control list). For a more detailed explanation, I recommend that you read Chapter 8 of the book “Windows Internals” by Mark Russinovich and David Solomon. Another good reference is the chapter on Authorization and Access Control Technologies of the Windows Server 2003 technical library.

For a quick explanation, I will try and put it in abstract terms: in Windows, all processes are authenticated and run in the user’s security context. A token is attached to each process, and this token contains, among others, the user’s IDs and all of the groups to which the user belongs. If you run the command whoami/all in a command line, you get a clear and readable view of your token. Because users and groups can change their names, they are located digitally with security IDs (Security Identifiers). Windows will usually do the translation for you.

Objects such as files have a Security Descriptor (SD), which contains a DACL (Discretionary Access Control List). This list contains ACE (Access Control Entries) and each ACE identifies an SID and an access type. For example: Users/Read, Administrative/Reading and Writing. If you run the command icacls file_name in a command line, you get a readable view of the file’s DACL (if icacls does not work, try cacls).

Simply put, when a process wants to reach an object for a given type of access (e.g. to change it), the Windows Security Reference Monitor (SRM) controls the object’s DACL, the token of the process, and it checks if one of the token’s SIDs is listed in an ACE that allows it access.

This mechanism is the same in all versions of Windows and even new concepts use it without any changes. For example, since the creation of Windows Vista, there is a new kind of SID: the service SID. The service SID identifies a service rather than a user or a group. It is used to ensure that even if two services S1 and S2 run under the same account (for example LOCAL SERVICE), a file can be accessed only by S1 by attaching an ACE belonging to the service SID, NT SERVICE\S1. This is the concept of service isolation addressed in the article by Cyril Voisin and Jean-Yves Poublan.

Therefore, since the introduction of Windows Vista, we find files that have ACEs referring to service SIDs. For example:

c:\Windows\notepad.exe
NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)

This means that only the service TrustedInstaller (full name: Windows Installer Modules) has all rights to the Windows files.

This was a very long introduction to a new kind of SID defined by Hyper-V: Virtual Machine SIDs. Much like the service SIDs, the VM SIDs are used to isolate the VMs; in other words, to ensure that a VM’s resources can only be accessed by that particular VM.

The following is the DACL of the VHD file of a virtual machine declared in Hyper-V:

dacl of the vhd file of a virtual machine declared in hyper-v

Remember, a VHD file is the virtual hard drive of the VM. Note the SID of the form NT VIRTUAL MACHINE\<GUID>. This GUID (090928A5-etc.) is the only Hyper-V identifier of this virtual machine. You can check this by looking at the file C:\ProgramData\Microsoft\Windows\Hyper-V\<GUID>.xml.

In Process Explorer, you can display the process properties (worker process) vmwp.exe corresponding to the VM:
process properties worker process vmwpexe corresponding to the vm

Also, displayed in Process Explorer, is the token of the process (Process Properties, Security tab):

process explorer is the token of the process properties security tab

This token and this DACL therefore ensure that:

1) the process (which runs as NETWORK SERVICE) will have access to reading and writing (but not eliminating) the VHD, and

2) the other VMs or services will not have access to writing.
By the way, did you notice that icacls and Process Explorer take advantage of Windows and always translate SID names as readable? Even I do not know if NT VIRTUAL MACHINE90928A5-E592-47E1-A819-85F56654EBCF is more readable than S-1-5-83-1-151595173-1205986706-4119140776-3488306278 … 🙂
If you want to know more about the advanced functions of Windows security tokens, see the series of articles by Cyril and Jean-Yves on the services in Windows Vista and Windows Server 2008.

 

The ideas in this article were highly inspired by pascals Article.

Comments

  1. That article helped clear a lot of my doubts. Thanks and keep up the good work 🙂

Trackbacks

  1. […] turns out that each VM in Hyper-V is assigned a unique SID in order to maintain a security separation between VM’s.  The VM SID is assigned an ACL on […]

Speak Your Mind

*