SDDL for Device Objects

The Security Descriptor Definition Language (SDDL) is used to represent security descriptors. Security for device objects can be specified by an SDDL string that is placed in an INF file or passed to IoCreateDeviceSecure. The Security Descriptor Definition Language is fully documented in the Microsoft Windows SDK documentation.

While INF files support the full range of SDDL, only a subset of the language is supported by the IoCreateDeviceSecure routine. This subset is defined here.

SDDL strings for device objects are of the form "D:P" followed by one or more expressions of the form "(A;;Access;;;SID)". The SID value specifies a security identifier that determines to whom the Access value applies (for example, a user or group). The Access value specifies the access rights allowed for the SID. The Access and SID values are as follows.

Note  When using SDDL for device objects, your driver must link against Wdmsec.lib.

Access
Specifies an ACCESS_MASK value that determines the allowed access. This value can be written either as a hexadecimal value in the form "0xhex", or as a sequence of two-letter symbolic codes that represent access rights.

The following codes can be used to specify generic access rights.

Code Generic access right

GA

GENERIC_ALL

GR

GENERIC_READ

GW

GENERIC_WRITE

GX

GENERIC_EXECUTE

The following codes can be used to specify specific access rights.

Code Specific access right

RC

READ_CONTROL

SD

DELETE

WD

WRITE_DAC

WO

WRITE_OWNER

Note that GENERIC_ALL grants all the rights listed in the above two tables, including the ability to change the ACL.

SID
Specifies the SID that is granted the specified access. SIDs represent accounts, aliases, groups, users, or computers.

The following SIDs represent accounts on the machine.

SID Description

SY

System

Represents the operating system itself, including its user-mode components.

LS

Local Service

A predefined account for local services (which also belongs to Authenticated and World). This SID is available starting with Windows XP.

NS

Network Service

A predefined account for network services (which also belongs to Authenticated and World). This SID is available starting with Windows XP.

The following SIDs represent groups on the machine.

SID Description

BA

Administrators

The built-in Administrators group on the machine.

BU

Built-in User Group

Group covering all local user accounts, and users on the domain.

BG

Built-in Guest Group

Group covering users logging in using the local or domain guest account.

The following SIDs describe the extent to which a user has been authenticated.

SID Description

AU

Authenticated Users

Any user recognized by the local machine or by a domain. Note that users logged in using the Builtin Guest account are not authenticated. However, members of the Guests group with individual accounts on the machine or the domain are authenticated.

AN

Anonymous Logged-on User

Any user logged on without an identity, such as an anonymous network session. Note that users logging in using the Builtin Guest account are neither authenticated nor anonymous. This SID is available starting with Windows XP.

The following SIDs describe how the user logged into the machine.

SID Description

IU

Interactive Users

Users who initially logged onto the machine "interactively", such as local logons and Remote Desktops logons.

NU

Network Logon User

Users accessing the machine remotely, without interactive desktop access (for example, file sharing or RPC calls).

WD

World

Before Windows XP, this SID covered every session, whether authenticated users, anonymous users, or the Builtin Guest account.

Starting with Windows XP, this SID does not cover anonymous logon sessions; it covers only authenticated users and the Builtin Guest account.

Note that untrusted or "restricted" code is also not covered by the World SID. For more information, see the description of the Restricted Code (RC) SID in the following table.

The following SIDs deserve special mention.

SID Description

RC

Restricted Code

This SID is used to control access by untrusted code. ACL validation against tokens with RC consists of two checks, one against the token's normal list of SIDs (containing WD for instance), and one against a second list (typically containing RC and a subset of the original token SIDs). Access is granted only if a token passes both tests. As such, RC actually works in combination with other SIDs.

Any ACL that specifies RC must also specify WD. When RC is paired with WD in an ACL, a superset of Everyone including untrusted code is described.

Untrusted code might be code launched using the Run As option in Explorer. By default, World does not cover untrusted code.

UD

User-Mode Drivers

This SID grants access to user-mode drivers. Currently, this SID covers only drivers that are written for the User-Mode Driver Framework (UMDF). This SID is available starting with Windows 8.

In earlier versions of Windows, which do not recognize the "UD" abbreviation, you must specify the fully qualified form of this SID (S-1-5-84-0-0-0-0-0) to grant access to UMDF drivers. For more information, see Controlling Device Access in the User-Mode Driver Framework documentation.

SDDL Examples For Device Objects

This section describes the predefined SDDL strings found in Wdmsec.h. You can also use these as templates to define new SDDL strings for device objects.

SDDL_DEVOBJ_KERNEL_ONLY

"D:P"

SDDL_DEVOBJ_KERNEL_ONLY is the "empty" ACL. User-mode code (including processes running as system) cannot open the device.

A PnP bus driver could use this descriptor when creating a PDO. The INF file could then specify looser security settings for the device. By specifying this descriptor, the bus driver would ensure that no attempt to open the device before the INF was processed would succeed.

Similarly, a non-WDM driver could use this descriptor to make its device objects inaccessible until the appropriate user-mode program (such as an installer) sets the final security descriptor in the registry.

In all of these cases, the default is tight security, loosened as necessary.

SDDL_DEVOBJ_SYS_ALL

"D:P(A;;GA;;;SY)"

SDDL_DEVOBJ_SYS_ALL is similar to SDDL_DEVOBJ_KERNEL_ONLY, except that in addition to kernel-mode code, user-mode code running as System is also allowed to open the device for any access.

A legacy driver might use this ACL to start with tight security settings, and let its service open the device up at run time to individual users by using the SetFileSecurity user-mode function. In this case, the service would have to be running as System.

SDDL_DEVOBJ_SYS_ALL_ADM_ALL

"D:P(A;;GA;;;SY)(A;;GA;;;BA)"

SDDL_DEVOBJ_SYS_ALL_ADM_ALL allows the kernel, system, and administrator complete control over the device. No other users may access the device.

SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_R

"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GR;;;WD)"

SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_R allows the kernel and system complete control over the device. By default the administrator can access the entire device, but cannot change the ACL (the administrator must take control of the device first.)

Everyone (the World SID) is given read access. Untrusted code cannot access the device (untrusted code might be code launched using the Run As option in Explorer. By default, World does not cover Restricted code.)

Also note that traversal access is not granted to normal users. As such, this might not be an appropriate descriptor for a device with a namespace.

SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_R_RES_R

"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GR;;;WD)(A;;GR;;;RC)"

SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_R_RES_R allows the kernel and system complete control over the device. By default the administrator can access the entire device, but cannot change the ACL (the administrator must take control of the device first.)

Everyone (the World SID) is given read access. In addition, untrusted code is also allowed to access code. Untrusted code might be code launched using the Run As option in Explorer. By default, World does not cover Restricted code.

Also note that traversal access is not granted to normal users. As such, this might not be an appropriate descriptor for a device with a namespace.

Note that the above SDDL strings do not include any inheritance modifiers. As such, they are only appropriate for device objects and should not be used for files or registry keys. For more information about specifying inheritance using SDDL, see the Microsoft Windows SDK documentation.