MSDN Magazine - November 2008 - (Page 60)

is allowed to do to an object or resource is specified in a data structure known as an ACL. ACLs enumerate who (which principal) has what kind of access to specific objects. A discretionary ACL (DACL) is a type of ACL where the owners of objects are allowed to change them. Whenever an object is accessed, the security descriptor is compared to the principal’s permissions to verify that the requested access is allowed. Note that Windows also supports system ACLs (SACLs) for objects and has used SACL settings to establish which events are logged to the audit log for many releases. With Windows Server 2008 and Windows Vista, SACL has been extended to carry integritylevel information. This integrity label is used to establish the “low” label that marks the Internet Explorer Figure 1 User Rights of Local Disk C process used in LowRights Internet Explorer. “System” and “high” labels are used to protect critical system resources. The Windows message pump filters messages based upon the integrity level of the message. For example, mediumlevel processes do not receive messages sent from low-level processes, and high-level processes do not receive messages from low- or medium-level processes. At this point, the integrity-level protection is a speed Figure 2 Advanced View of User Rights over Drive C bump, not a true security barrier about which you can make security guarantees. The height of this bump will increase significantly in later releases when it is likely to become a real security barrier. As with other modern OSs, Windows relies on DACLs for general access-control decisions. Here I will focus primarily on DACLs. For the system to determine whether a principal is allowed to perform an operation upon an object, several things are checked: the principal’s privileges, the principal’s token, and the object’s security descriptor. The binary security descriptor on an object is passed to the AccessCheck routine with the principal’s token. A requested access mask bit vector is prepared, representing the access rights that must be granted for the access check to succeed. It is passed with the principal’s security Figure 3 Edit View of User Special Rights 60 msdn magazine descriptor to the AccessCheck routine, which examines the user’s security token and considers the principal’s privileges (typically based on roles or membership, such as administrator) in combination with the requested access and the DACL on the object. If the requested access is satisfied by the principal’s privileges, access is granted. Otherwise, the DACL access control entries (ACEs) are examined in order. As soon as the security system is able to show that all requested access components are allowed or that any of them is denied, it returns a success in the former case and a failure in the latter. Thus, the DACL’s list of ACEs should be appropriately ordered. The standard (canonical) ordering is to first place explicit denies, then explicit allows, general (group) denies, and group allows. If the canonical ordering isn’t used, unanticipated allows or denies may occur. While the security descriptor is a binary data structure, it relies on the security descriptor string format to provide a somewhat human-readable text format. A string format security descriptor is represented as a null-terminated string with tokens to indicate each of the four main components: owner (O:), primary group (G:), DACL (D:), and SACL (S:), as Figure 4 illustrates. Security Identifiers (SIDs) are structured to provide parsing information and include 96 bits of random information (and may include 32 bits of sequence count) to serve as a unique identifier for owners. The string_aces (ACEs expressed in string format) are the structures that explicitly grant or deny permissions in the DACL and set policy in the SACL. Each string_ace is enclosed in parentheses and has the following structure: (ace_type;ace_flags;rights;object_guid;inherit_ object_guid;account_sid) Object Security Descriptors Only those grants that are necessary for proper access to the object in question must be present. Frequently the owner_sid and group_sid are omitted from the security descriptor. If not explicitly specified at creation File and Registry Permissions

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.