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.

Security descriptors

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.

Control flag

Definition

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.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy