How is privilege used in Windows XP, NT, 2000 and 2003. What are DACLs and SACLs

This is the first part of a three part response to a comment made by Matt in his comment regarding the least privilege model in Windows Vista.

Let's review how privilege is used in Windows NT, XP, 2000 and 2003:

Objects including files, services and the registry are protected using Discretionary Access Control Lists - these are known as DACLs and often shortened to "ACLs".

DACLs are created by the owner of the object to describe which users and groups are able to access and manipulate it. Objects receive DACLs as they are created on the system. DACLs can be set explicitaly or inherited from parent objects in the file system / registry hierarchy. DACLs can include the attributes "Read", "Write", "Execute", "Delete". I have omitted the remaining attributes as this post is complicated enough!

No summary of the Windows Access Control mechanism would be complete without mentioning System Access Control Lists (SACLs). SACLs are used to control the generation of audit messages pertaining to attempts to access the object. Administrative privilege is required to configure SACLs.

Note: the access control mechanism is very similiar for UNIX / LINUX.  The permissions available in UNIX / LINUX differ slightly from those in Windows though many of the principles are very similar.

In UNIX / LINUX the registry is replaced with a plethora of plain text configuration files each of which are covered by the access control mechanism for files.

Administrative privilege is required to over-ride Access Control Lists and therefore standard users (those without additional privilege) are forced to comply with their stipulations.

The operating system including it's configuration objects are protected by DACLs specifying that only system administrators (defined by group membership or specific privilege) can make changes.

It is possible for the system administrator to relax the access controls for the operating system THOUGH THIS IS NOT RECOMMENDED technically such changes invalidate your support contract and the resulting system may be insecure and unstable.

Installing software and reconfiguring the system typically requires "Write" access to areas of the registry and the filesystem. If a standard user attempts to carry out these tasks they will be prevented from doing so by the operating system. 



Comments (3)

  1. Anonymous says:

    This is the second part of a three part response to a comment made by Matt in his comment regarding…

  2. Anonymous says:

    This is the final part of a three part response to a comment made by Matt in his comment…

  3. Matt Dickins says:

    There I was thinking half way through post "mmm. CHMOD-ing" (I’m not a IIS user atm, go for LAMP configs atm) then I saw your reference to Linux & UNIX :).

    Good info there, thanks.

Skip to main content