IT:AD:Design:Investigations:Security:Authorisation:DAC:Security Descriptors

(UP)

Some Objects are Hierarchical, others, not: * Hierarchical (Files/Folders) * Not (Printers, Services)

In a DB System the ACL can be associated to the Entity Table, or Type (Contact).

SDs, Trustees, SIDs, ACLs, ACEs

To each Object is associated a Security Descriptor (SD)
- An SD contains:
  - The object's current Owner (the Trustee: which is a User, Group, Computer)
    - Expressed as a SID.
      - when expressed as a string looks similar to S-1-5-32-544.
      - requires an additional service to translate SID→User, and viceversa (SAM on local machine, and AD in Domains).
    - A binary data structure
  - The Object's primary Group (rarely used)
    - Expressed as a SID.
  - The Discretionary Access Control List (DACL):
    - Which is a collection of n Access Controle Entries (ACE)
      - of either type Access Allowed ACE or Access Denied ACE
      - Each ACE specifies the Operations a single Trustee can/cannot do (note: one ACE per Trustee).
      - eg: “Users: Allow Read”, “Admins: Allow Write”, “Susan (although Admin): Deny Write”, etc.
  - The System Access Control List (SACL):
    - Which is a collection of n ACE entries
      
      of type System Audit ACE (only one type used in a SACL).
      
      Each ACE specifies which Operations by Group/User causes an Log Entry in the Security Log.
      
      eg: “Log Write Operations by Users”
      
      Control information
      
      REF:Post

Access Control Entries (ACE)

Each ACE contains:
- The Trustee's SID.
- Access bitmask containing permissions to grant/deny(DACL) or audit (SACL).
  - The bitmask's flags mean different things, depending on the Object's Type (File, Folder, etc.).
- Inheritence Flag
  - If inherited, no changes can be made on this entry.
  - I believe the BitMask will be a copy of the parent entry. If so:
    - No need to recurse up to get value of ACE.
    - Changes to the parent ACE need to be repropagated to all the children Inherited.
      
      If there was a FK pointing back to the parent ACE, this could be rather easy to implement.
http://msdn.microsoft.com/en-us/library/aa379607(v=vs.85).aspx.aspx)

Example:

[Flags]
enum ACCESS_MASK : uint
{
     DELETE = 0x00010000,
     READ_CONTROL = 0x00020000,
     WRITE_DAC = 0x00040000,
     WRITE_OWNER = 0x00080000,
     SYNCHRONIZE = 0x00100000,

     STANDARD_RIGHTS_REQUIRED = 0x000f0000,

     STANDARD_RIGHTS_READ = 0x00020000,
     STANDARD_RIGHTS_WRITE = 0x00020000,
     STANDARD_RIGHTS_EXECUTE = 0x00020000,

     STANDARD_RIGHTS_ALL = 0x001f0000,

     SPECIFIC_RIGHTS_ALL = 0x0000ffff,

     ACCESS_SYSTEM_SECURITY = 0x01000000,

     MAXIMUM_ALLOWED = 0x02000000,

     GENERIC_READ = 0x80000000,
     GENERIC_WRITE = 0x40000000,
     GENERIC_EXECUTE = 0x20000000,
     GENERIC_ALL = 0x10000000,

     DESKTOP_READOBJECTS = 0x00000001,
     DESKTOP_CREATEWINDOW = 0x00000002,
     DESKTOP_CREATEMENU = 0x00000004,
     DESKTOP_HOOKCONTROL = 0x00000008,
     DESKTOP_JOURNALRECORD = 0x00000010,
     DESKTOP_JOURNALPLAYBACK = 0x00000020,
     DESKTOP_ENUMERATE = 0x00000040,
     DESKTOP_WRITEOBJECTS = 0x00000080,
     DESKTOP_SWITCHDESKTOP = 0x00000100,

     WINSTA_ENUMDESKTOPS = 0x00000001,
     WINSTA_READATTRIBUTES = 0x00000002,
     WINSTA_ACCESSCLIPBOARD = 0x00000004,
     WINSTA_CREATEDESKTOP = 0x00000008,
     WINSTA_WRITEATTRIBUTES = 0x00000010,
     WINSTA_ACCESSGLOBALATOMS = 0x00000020,
     WINSTA_EXITWINDOWS = 0x00000040,
     WINSTA_ENUMERATE = 0x00000100,
     WINSTA_READSCREEN = 0x00000200,

     WINSTA_ALL_ACCESS = 0x0000037f
}