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:

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.

Also, displayed in Process Explorer, is the token of the process (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

 

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