什么是安全描述符？

see also:http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsASecurityDescriptor.html

Each object protected by the Windows discretionary access control system must have some state associated with it to track its security settings. This little bundle of state is often referred to as a "security descriptor." Logically, here's what that state must contain:

• Owner SID (WhatIsOwnership)
• Group SID
• DACL: Discretionary Access Control List (WhatIsAnAccessControlList)
• SACL: System Access Control List (WhatIsAnAccessControlList)
• Control flags

Windows doesn't document how this little bundle of state is physically stored for each type of object, but we do know that there’s no global repository. So the security settings for a file, for example, will be stored as metadata somewhere in the NTFS file system. The registry also must have some metadata for each key that can hold this state. These two examples you can’t see because this metadata is hidden from view. But in other cases you can actually see some of these little bundles. For example, if you bring up the registry editor (run it as an administrator) and drill down into the service database to, say, HKLM/SYSTEM/CurrentControlSet/Services/ClipSrv, you'll see a subkey under the service's key called Security and a binary named value that contains this state, as shown in Figure 42.1.

Figure 42.1 Security descriptor for the clipbook service

What you're looking at is a serialized security descriptor that contains all the information I enumerated earlier (owner SID, DACL, etc.) The service control manager uses this information to figure out who should be allowed to start and stop the Clipbook service ¹. Similarly, if you poke around in the file server's section of the registry, you'll see that each share tracks its security settings in a similar way (Figure 42.2).

Figure 42.2 Security descriptor for the wwwroot$ file share

Here's what the components of an object's security descriptor mean. The owner SID is the user ² that is always allowed to control the DACL of the object. In layman's terms, this means that the owner can control who is allowed to use the object and in what ways. See WhatIsOwnership for more about ownership.

The group SID, also known as the "primary group," isn't used at all by Win32 applications. It's actually there to support UNIX applications that run in the optional POSIX subsystem. If you’re familiar with the UNIX file system (Stevens, 1990), recall that each file has an owner and a group associated with it and that permissions can be granted to three entitites: owner, group, and world. So the group SID is a way of tracking a group for each object, which allows support for UNIX-style permissions. As a Windows programmer, you can safely ignore this SID. If you want to write UNIX apps, pull out your Linux box, already. ³

The discretionary access control list (DACL) contains a list of permissions granted or denied to various users and groups. The reason it's called "discretionary" is that the owner of the object is always allowed to control its contents. Contrast this to the system access control list (SACL), over which the owner has no special control. In fact, usually the owner of an object isn't even allowed to read it. The SACL is designed for use by security officers, and it specifies what actions will be audited by the system. I like to think of the SACL as the "Big Brother" bits. To learn more about how ACLs work, see WhatIsAnAccessControlList.

Finally, there are two control flags that arguably should be part of the DACL and SACL headers but instead are specified as part of the security descriptor.

• SE_DACL_PROTECTED
• SE_SACL_PROTECTED

These flags control the flow of inherited Access Control Entries (ACE)s in a hierarchical system. Check out WhatIsACLInheritance to learn more about how this works. Note that there are several other control flags defined for a security descriptor; however, they aren't actually persisted with the object, and most are so historical in nature that you won't ever need to know about them. Consider yourself lucky.

As a .NET developer, you should also consider yourself lucky because version 2.0 brings a managed representation of security descriptors and ACLs to the party. The abstract base class that defines the basic functionality of a security descriptor is called ObjectSecurity, and two concrete derived classes represent security descriptors for simple objects or container nodes in a hierarchy of objects: LeafObjectSecurity and ContainerObjectSecurity, respectively. The former is the class you'll usually use if you need to program ACLs (HowToProgramACLs) on simple objects such as files, file shares, services, or kernel objects like processes and threads. The container class deals with container nodes in a hierarchical system, including folders and registry keys, where ACL inheritance (WhatIsACLInheritance) is more of an issue. As you'll see in HowToProgramACLs, these classes really simplify programming security descriptors.

¹ Technically there are many other actions besides starting and stopping the service that are also controlled by the service’s DACL: pause, resume, reconfigure, delete, etc.

² The owner can be a group in one special case that I document in WhatIsOwnership.

³ Apparently some devs at Microsoft do some UNIX work on the sly: Many of them have stickers on their laptop lids proclaiming, “My other machine is your Linux box!”