Get a glimpse inside Paul Cooke's e-book "The definitive guide to Windows 2000 security" with this series of book excerpts, courtesy of Realtimepublishers.com. This excerpt is from Chapter 5, "Configuring access control." Click for the book excerpt series or get the full e-book.
While you now know that ACEs are contained in an ACL, it's time to talk about where ACLs are used. You might think that ACLs are applied directly to an object, but in reality, all access control information for an object is encapsulated in a data structure known as a security descriptor. As Windows 2000 manipulates an object, its security descriptor determines whether to allow or deny access. While the exact makeup of a security descriptor depends on the type of object that it's associated with, a security descriptor's contents follow a general formula:
- The owner of the object
- The users and groups that are allowed or denied access to the object
- The users and groups that should have their access to the object audited
- The rules for how objects in a container inherit access control information from the container
In addition to this general information, Figure 5.14 depicts what the variable-length binary data structure looks like.
Figure 5.14: The structure of a security descriptor.
As you can see, a security descriptor has five major sections.
- Header -- Contains both a revision number for the structure and a set of flags that indicate which structure elements are present, where the elements are located relative to the beginning of the structure, and other general characteristics of the overall data structure.
- Owner SID -- As it sounds, the SID of the security principal that owns the object.
- Group SID -- Is included only for use by Portable Operating Systems Interface for UNIX (POSIX) subsystems and is totally ignored by the rest of Windows 2000.
- SACL -- Contains the ACL for the accounts and groups that should be audited when they access the object.
- DACL -- Holds the ACL for the accounts and groups that can access the object.
I've pretty much covered the rest of the fields contained in a security descriptor, so I want to take a quick look at the most important portion of the header, the control flags. The control flags are important to a security descriptor because they control how ACEs from this security descriptor will be propagated using inheritance to a child object's security descriptor. Flags are stored as simple bit fields and are shown in Table 5.5 along with Microsoft's definitions.
|SE_DACL_AUTO_INHERITED||Inheritable ACEs in this object's DACL have been propagated to existing child objects.|
|SE_DACL_DEFAULTED||The DACL was provided by a default mechanism.|
|SE_DACL_PRESENT||The security descriptor has a DACL.|
|SE_DACL_PROTECTED||The security descriptor's DACL cannot be modified by inheritable ACEs.|
|SE_GROUP_DEFAULTED||The primary group SID was provided by a default mechanism.|
|SE_OWNER_DEFAULTED||The owner SID was provided by a default mechanism.|
|SE_SACL_AUTO_INHERITED||Inheritable ACEs in this object's SACL have been propagated to existing child objects.|
|SE_SACL_DEFAULTED||The SACL was provided by a default mechanism.|
|SE_SACL_PRESENT||The security descriptor has a SACL.|
|SE_SACL_PROTECTED||The security descriptor's SACL cannot be modified by inheritable ACEs.|
|SE_SELF_RELATIVE||The security descriptor is in self-relative format with all information in a contiguous block of memory. If this flag isn't set, the security descriptor is in absolute format.|
Table 5.5: Security descriptor control flags.
When an object is created, its security descriptor is populated with values and can of course be modified later. But no matter when the information is put into the security descriptor, the information can only come from one of three sources: the owner/creator, a parent object, or the object manager. When an object is being created, these three sources of information are applied in this order. For example, when a new object is created, the owner can explicitly assign a security descriptor to the object but doesn't have to. If the owner doesn't supply a security descriptor, Windows 2000 tries to build one using values inherited from parent objects. If no access control information is inherited down to the new object, Windows 2000 turns to the object manager to supply the default access control information for the object, based on the object's type.
After the object is created, the access control information it contains can be modified by the object's owner or someone who's been granted permission to change the security descriptor information. The security descriptor can also be modified when the security descriptor of a parent object is modified. So each time a parent's security descriptor is modified, the object manager is responsible for propagating inheritable changes to all the objects in the container; these changes will in turn cascade down the next level of children.
The last important thing to say about security descriptors is that security descriptors is where, and why, every object gets its owner. As I discussed earlier in this chapter, each and every object must have an owner; therefore, the Owner SID field of a security descriptor is never blank. The owner of an object can never be denied the right to allow or deny other users permission to access the object. So even if you lose the ability to read one of your own files, as long as you're the owner, you can always recover your ability to access the file.
Click for the next excerpt in this series: Access tokens
Click for the book excerpt series or get the full e-book.
This was first published in November 2004