Throughout my discussions of access control and ACLs in this book, I will often talk about permissions as numbers. For example, I might talk about 0x1FF as being a set of permissions, or granting "permission 1 and 2" to someone. What I'm doing is being very generic and using literal access masks or numbered permissions. I'm not specifying just what types of objects I'm talking about; I'm just talking about how access control works for all different types of objects.
So let's make this concrete and look at some examples of permissions for some specific types of objects in Windows. Let's start with, oh, a registry key. Peeking at a Win32 header file called winnt.h shows us the following1:
// excerpt from winnt.h
#define KEY_QUERY_VALUE (0x00000001)
#define KEY_SET_VALUE (0x00000002)
#define KEY_CREATE_SUB_KEY (0x00000004)
#define KEY_ENUMERATE_SUB_KEYS (0x00000008)
#define KEY_NOTIFY (0x00000010)
#define KEY_CREATE_LINK (0x00000020)
Let's also look at the permission definitions for a thread:
// excerpt from winnt.h
#define THREAD_TERMINATE (0x00000001)
#define THREAD_SUSPEND_RESUME (0x00000002)
#define THREAD_GET_CONTEXT (0x00000008)
#define THREAD_SET_CONTEXT (0x00000010)
#define THREAD_SET_INFORMATION (0x00000020)
#define THREAD_QUERY_INFORMATION (0x00000040)
#define THREAD_SET_THREAD_TOKEN (0x00000080)
#define THREAD_IMPERSONATE (0x00000100)
#define THREAD_DIRECT_IMPERSONATION (0x00000200)
If you wanted to grant Alice permission to create a new registry key under some existing key, you'd edit the existing key's DACL and add an ACE ( What Is An Access Control List ) that grants Alice the KEY_CREATE_SUB_KEY permission. Pretty simple. But look at those permissions again and tell me how you'd grant Alice the permission to delete the key she just created!
That's right, the registry subsystem doesn't bother defining a permission for deleting a key. That's because it's such a common permission (most secure objects can be deleted) that it's included as part of a standard set of permissions that are common across all types of objects. Here are the standard permissions that are allowed to be put in an ACL:
// excerpt from winnt.h
#define DELETE (0x00010000L)
#define READ_CONTROL (0x00020000L)
#define WRITE_DAC (0x00040000L)
#define WRITE_OWNER (0x00080000L)
#define SYNCHRONIZE (0x00100000L)
Compare the numerical layout of the standard permissions to the specific permissions defined for registry keys. Note how the standard permissions all fall in the upper word of the 32 bit mask, while the specific permissions are defined in the lower word. Notice the same technique is used for the thread permissions. You see, each class of object is allowed to define up to 16 specific permissions, and they must all be in that lower word, so they don't conflict with permissions Microsoft has already defined for all objects, such as the standard permissions shown above.
The standard permissions are really quite straightforward. Let me briefly explain what they mean. READ_CONTROL ("Read Permissions") controls whether you can read the owner and DACL in the object's security descriptor. If you don't have this permission, you're not even allowed to see what permissions you do have! WRITE_DAC ("Write Permissions") and WRITE_OWNER ("Take Ownership") say whether you're allowed to change the object's DACL or take ownership of the object by changing the owner SID to be your own SID (for more detail, see What Is Ownership ). SYNCHRONIZE says whether you can wait on an object (this is most often used with synchronization objects such as a mutex or semaphore). By limiting SYNCHRONIZE access, you can prevent an untrusted user from grabbing a mutex that your program depends on and deadlocking you. And DELETE is pretty obvious.
Let's say you want to grant Alice permission to read a registry key. It'd make sense to grant her a combination of the following:
- KEY_QUERY_VALUE
- KEY_ENUMERATE_SUB_KEYS
- KEY_NOTIFY
- READ_CONTROL
If you binary OR these values together, you'll end up with 0x00020019. This would be the access mask you'd put into the ACE ( What Is An Access Control List ) to grant Alice read access to the key. For an example of code that modifies an ACL programmatically, check out How To Program ACLs .
Look at the following access mask and try to figure out what it means: 0x00130000. The answer is in the following footnote2. Now try to decode this one: 0x00000001. Surely this one is easier! Oh wait, I didn't tell you what type of object we're talking about. I mean, if it were a registry key, this would be KEY_QUERY_VALUE -a fairly benign permission to grant, at least compared to THREAD_TERMINATE! You see, given a random permission mask, you really can't tell what it means unless you know the type of object to which it applies, unless it simply consists of standard permissions, which are defined centrally for all objects.
With this in mind, think about a permission mask that would be generic enough to grant read permission to any type of object in the system, including registry keys and threads. For a registry key, we'd want 0x00020019, as we calculated earlier for Alice. But for a thread, it'd be 0x00020048. That's a very different mask. As you can see, because no two types of objects can be expected to have the same sorts of permissions, at first glance it'd be impossible to treat objects polymorphically with respect to permissions. But if you look a bit further into winnt.h, you'll find the following rather interesting definitions:
// excerpt from winnt.h
#define GENERIC_READ (0x80000000L)
#define GENERIC_WRITE (0x40000000L)
#define GENERIC_EXECUTE (0x20000000L)
#define GENERIC_ALL (0x10000000L)
What do you think would happen if you added an ACE to a registry key's DACL that granted Alice GENERIC_READ? Think about it for a moment. If you guessed that the system would convert the access mask from 0x80000000 to 0x00020019 before storing the new DACL in the metadata for the registry key, then you'd be correct. You see, each class of object in Windows defines a mapping from these four generic permissions onto standard and specific permissions. This allows us to make statements like, "By default, I'd like to grant full control to SYSTEM and myself for any object I create. Oh and I'd also like Alice to have read access as well." Here's a text representation of just such a DACL:
grant SYSTEM 0x10000000
grant Keith 0x10000000
grant Alice 0x80000000
It turns out that Windows makes a statement like this for every process! You see, inside the token ( What Is A Token ) is a default owner and DACL that are used whenever you create new objects3. For example, if you were to create a thread, how would the system know what the DACL for that thread should look like? Well, it looks at this default DACL that's tucked away inside your token.
Here's what a default DACL would look like for me on my laptop4:
grant SYSTEM 0x10000000
grant Keith 0x10000000
So by default, any new threads that I create, or semaphores, shared memory sections and so on, start life with DACLs that specifically grant my account and SYSTEM full control. Nobody else will be able to touch the objects I create, barring specially privileged users such as administrators ( What Is A Privilege ). Note that hierarchical systems like the file system and registry instead use ACL inheritance to come up with a default DACL; this ensures that permissions remain consistent through the branches of the hierarchy. See What Is ACL Inheritance for the details.
The default DACL is one of the few mutable bits of data in a token. In most cases you shouldn't ever need to change this DACL, as it's already about as tightly secured as it can be. If you ever find the need to adjust it, you'll want to look at the Win32 function SetTokenInformation.
- I've omitted three permissions that are specific to 64-bit Windows for brevity.
DELETE,READ_CONTROL, andSYNCHRONIZE.- By "objects" I mean any object that has a security descriptor ( What Is A Security Descriptor ), such as a process, thread, mutex, etc.
- If you want to do this experiment, you should download the Token Dump component from my website. I don't know of any built-in tool that shows this information.
