SDDL – easier to read, except when it’s not.

SDDL was introduced by Microsoft in Windows 2000, as a counter to the difficulty developers had in writing (and administrators had in reading) Security Descriptors, and specifically the Access Control Lists that come with them.


The recent advisory about service security settings (the title says “possible vulnerability” – as far as I’m concerned, it’s definite – I’ve exploited it on a couple of our own machines in XP SP1) led me to check on some other services, particularly the one that I make and sell.


My service turned out to be alright, and then a friend emailed me to ask about our favourite target: Quickbooks.  The new Quickbooks 2006 includes a system service.  I got Susan to list the SD on the service:


 C:\Documents and Settings\Administrator>sc sdshow QuickBooksDB


D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)S: (AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)


Wow – that’s confusing, isn’t it?  Okay, let’s deconstruct it – “D:” at the start indicates it’s a “Discretionary ACL” or “DACL” – this is a list of things that users / groups can / cannot do.  The “S:” towards the end is for a “SACL” – “System ACL”, which lists what gets logged.


Let’s look at a sample DACL Access Control Entry (ACE):


(A;;CCLCSWRPWPDTLOCRRC;;;SY)


The “A” means “Allow” – this ACE lists what the user is allowed to do.  The “SY” means that the user being described is the local system.


The rights in the middle are made up of selections of pairs of letters:


CC – SDDL_CREATE_CHILD
LC – SDDL_LIST_CHILD
SW – SDDL_SELF_WRITE
RP – SDDL_READ_PROPERTY
WP – SDDL_WRITE_PROPERTY
DT – SDDL_DELETE_TREE
LO – SDDL_LIST_OBJECT
CR – SDDL_CONTROL_ACCESS
RC – SDDL_READ_CONTROL


So, that explains it, right?  Well, not exactly – what does it mean to “Create Child” on a service?  To “List Child” on a service?


After a lot of looking, I find that there really isn’t any sensible meaning to those.  The trick is to ignore those names.  Instead, think of the pairs of letters as representing numbers:


CC is listed as being equivalent to SDDL_CREATE_CHILD, or ADS_RIGHT_DS_CREATE_CHILD – and that last name has the value ‘1’ in the header file IADS.H.


Oh yes, you have to have the Platform SDK or other source of Windows Include Files to figure this out.


Then you go to the header file WinSvc.h, and find that SERVICE_QUERY_CONFIG is a right, and has the value 1.


Yuck.


To help you, I did the work and came up with:


CC – SERVICE_QUERY_CONFIG – ask the SCM for the service’s current configuration
LC – SERVICE_QUERY_STATUS – ask the SCM for the service’s current status
SW – SERVICE_ENUMERATE_DEPENDENTS – list dependent services
RP – SERVICE_START – start the service
WP – SERVICE_STOP – stop the service
DT – SERVICE_PAUSE_CONTINUE – pause / continue the service
LO – SERVICE_INTERROGATE – ask the service its current status
CR – SERVICE_USER_DEFINED_CONTROL – send a service control defined by the service’s authors
RC – READ_CONTROL – read the security descriptor on this service.


SDDL turns out to be absolutely no use whatever in figuring any of this out, and I couldn’t find a tool on Microsoft’s site that adequately lists service rights in such a way that an admin might understand them.  Maybe I’m just not looking in the right place – if you know of any, please let me know!


Is it any wonder that there’s a difficulty with service writers and administrators incorrectly setting access rights?  How do you guys configure security descriptors on objects like services?

1 thought on “SDDL – easier to read, except when it’s not.”

  1. I took a long time to figure this thing out.
    The SDDL rights abbreviations are confusing in many places because those abbreviations and constants are intended for Active Directory objects only, and confusing anywhere else. (They don’t even map well to NTFS files and folder permissions – a bad design at the start.)

    The only reliable way to find these letter pairs mean is to map them to mask bits; then translate the bits to the rights your particular service provides.

    First the letter pairs to mask bits (references [1][2]):
    CC – ADS_RIGHT_DS_CREATE_CHILD – 0x1
    DC – ADS_RIGHT_DS_DELETE_CHILD – 0x2
    LC “LIST_CHILDREN” – ADS_RIGHT_ACTRL_DS_LIST – 0x4
    SW “SELF_WRITE” – ADS_RIGHT_DS_SELF – 0x8
    RP – ADS_RIGHT_DS_READ_PROP – 0x10
    WP – ADS_RIGHT_DS_WRITE_PROP – 0x20
    DT – ADS_RIGHT_DS_DELETE_TREE – 0x40
    LO – ADS_RIGHT_DS_LIST_OBJECT – 0x80
    CR – ADS_RIGHT_DS_CONTROL_ACCESS – 0x100

    (Bits 16-31 are unlikely to differ among services. These include:)
    SD – Standard Delete – 0x10000
    RC – Read Control – 0x20000
    WD – Write DAC – 0x40000
    WO – Write Owner – 0x80000
    0x100000 – Synchronize (note: no letter pair for this)
    GA – Generic All – 0x10000000
    GX – Generic Execute – 0x20000000
    GW – Generic Write – 0x40000000
    GR – Generic Read – 0x80000000

    Then look at how mask bits are used in a particular service, for example I want to set NTFS file permissions (reference [3]; abbreviation used in ICACLS command included for convenience):
    0x1 – List folder / read data (RD)
    0x2 – Create files / write data (WD)
    0x4 – Create folders / append data (AD)
    0x8 – Read extended attributes (REA)
    0x10 – Write extended attributes (WEA)
    0x20 – Traverse folder / execute file (X)
    0x40 – Delete subfolders and files (DC)
    0x80 – Read attributes (RA)
    0x100 – Write attributes (WA)

    So a Write Attributes permission of a file corresponds to CR in SDDL.

    [1] https://msdn.microsoft.com/en-us/library/aa374928(v=vs.85).aspx
    [2] https://msdn.microsoft.com/en-us/library/aa772285(v=vs.85).aspx
    [3] https://msdn.microsoft.com/en-us/library/gg258116(v=vs.85).aspx

Leave a Reply

Your email address will not be published. Required fields are marked *