2.4.5 ACL
The access control list (ACL) packet is used to specify a list of individual access control entries (ACEs). An ACL packet and an array of ACEs comprise a complete access control list.
The individual ACEs in an ACL are numbered from 0 to n, where n+1 is the number of ACEs in the ACL. When editing an ACL, an application refers to an ACE within the ACL by the ACE index.
In the absence of implementation-specific functions to access the individual ACEs, access to each ACE MUST be computed by using the AclSize and AceCount fields to parse the wire packets following the ACL to identify each ACE_HEADER, which in turn contains the information needed to obtain the specific ACEs.
An ACL is said to be in canonical form if:
All explicit ACEs are placed before inherited ACEs.
Within the explicit ACEs, deny ACEs come before grant ACEs.
Deny ACEs on the object come before deny ACEs on a child or property.
Grant ACEs on the object come before grant ACEs on a child or property.
Inherited ACEs are placed in the order in which they were inherited.
There are two types of ACL:
A discretionary access control list (DACL) is controlled by the owner of an object or anyone granted WRITE_DAC access to the object. It specifies the access particular users and groups can have to an object. For example, the owner of a file can use a DACL to control which users and groups can and cannot have access to the file.
A system access control list (SACL) is similar to the DACL, except that the SACL is used to audit rather than control access to an object. When an audited action occurs, the operating system records the event in the security log. Each ACE in a SACL has a header that indicates whether auditing is triggered by success, failure, or both; a SID that specifies a particular user or security group to monitor; and an access mask that lists the operations to audit.
The SACL also MAY contain<71> a label ACE that defines the integrity level of the object.
The only valid ACE types for a SACL are the auditing types (SYSTEM_AUDIT_ACE_TYPE, SYSTEM_AUDIT_OBJECT_ACE_TYPE, SYSTEM_AUDIT_CALLBACK_ACE_TYPE, and SYSTEM_AUDIT_CALLBACK_OBJECT_ACE_TYPE), the label type (SYSTEM_MANDATORY_LABEL_ACE_TYPE), the system resource attribute type (SYSTEM_RESOURCE_ATTRIBUTE_ACE_TYPE), and the scoped policy type (SYSTEM_SCOPED_POLICY_ID_ACE_TYPE), as specified in section 2.4.4.1.
The SACL MUST NOT contain ACEs that belong in the DACL, and the DACL MUST NOT contain ACE types that belong in the SACL. Doing so results in unspecified behavior.
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
AclRevision |
Sbz1 |
AclSize |
|||||||||||||||||||||||||||||
|
AceCount |
Sbz2 |
||||||||||||||||||||||||||||||
AclRevision (1 byte): An unsigned 8-bit value that specifies the revision of the ACL. The only two legitimate forms of ACLs supported for on-the-wire management or manipulation are type 2 and type 4. No other form is valid for manipulation on the wire. Therefore this field MUST be set to one of the following values.
-
Value
Meaning
ACL_REVISION
0x02
When set to 0x02, only AceTypes 0x00, 0x01, 0x02, 0x03, 0x11, 0x12, and 0x13 can be present in the ACL. An AceType of 0x11 is used for SACLs but not for DACLs. For more information about ACE types, see section 2.4.4.1.
ACL_REVISION_DS
0x04
When set to 0x04, AceTypes 0x05, 0x06, 0x07, 0x08, and 0x11 are allowed. ACLs of revision 0x04 are applicable only to directory service objects. An AceType of 0x11 is used for SACLs but not for DACLs.
Sbz1 (1 byte): An unsigned 8-bit value. This field is reserved and MUST be set to zero.
AclSize (2 bytes): An unsigned 16-bit integer that specifies the size, in bytes, of the complete ACL, including all ACEs.
AceCount (2 bytes): An unsigned 16-bit integer that specifies the count of the number of ACE records in the ACL.
Sbz2 (2 bytes): An unsigned 16-bit integer. This field is reserved and MUST be set to zero.