Security principals and access to objects

Security in Windows is based on the subject-object-actions relationship. When a subject requests to perform some actions on an object, the operating system checks whether the access should be granted based on security permissions associated with that object. According to [61], a subject (security principal) can be: a user, a computer, and a service (starting with Windows Vista and Windows Server 2008). An object can be [62]: a file, a device, a job, a process, a thread, shared memory sections, volumes, etc.

To make a decision whether to grant some principal access to an object, the operating system must know the identity of the principal. Therefore, prior to be able to access resources a user must authenticate to the system during the Windows logon process. Windows uses unique security identifiers (SIDs) to identify security principals. A SID is assigned during the logon process.

The structure of the SID:

S – 1 – 5 – 21 – 2443930396 – 124871960 – 1960245352 – 1000 Domain identifier RID  S – SID designator. Consists of character "S";

 1 – revision number of the SID specification;

 5 – authority identifier. For SECURITY_NT_AUTHORITY the value is 5. Other possible values are: SECURITY_WORLD_SID_AUTHORITY,

SECURITY_LOCAL_SID_AUTHORITY, etc;

 Domain identifier – identifies a domain or computer that issued SID;

 RID – Relative identifier. RIDs are used to ensure uniqueness of SIDs. RIDs for non-default users and groups start with 1000 and increase by 1 for every new principal.

All accounts (users and groups) in the Windows system can be divided in two classes: user-defined and automatically created by the system. Automatically created groups can be further divided in built-in and system groups. System groups have automatic and dynamic membership that is dependent on the principal's activity type. Built-in groups, on the other hand, are not much different from user-defined groups and are used to support a default Windows security model [63].

Some well-known built-in accounts in the Windows system.

Table 3.1.1.1: Built-in accounts in Windows

SID user/group description

35 S-1-5-domain-501 Guest Built-in account that can be used to give limited

access to those who do not have personal account

S-1-5-domain-502 KRBTGT Service account used by Kerberos KDC

S-1-5-domain-512 Domain Admins Members of this group are authorized to administer a domain.

S-1-5-domain-513 Domain Users Includes all user accounts in a domain

S-1-5-domain-515 Domain Computers This group includes client stations and servers in a domain

S-1-5-32-544 Administrators Initially contains Administrator account as the only member. After the system joins a domain, Domain Admins group is added to this group.

Table 3.1.1.2: Well-known system groups in Windows

S-1-1-0 Everyone This group includes completely all users

S-1-2-0 Local This group includes users who log on to computer locally via connected terminal

S-1-5-2 Network Contains users who log on via a network

S-1-5-4 Interactive Includes users that log on interactively. Terminal server users are in this group, but they are not included in Local group [61].

S-1-5-5-X-Y Logon Session This SID is used to identify a logon session, not a principal. Each logon session of a user is assigned a unique ID (X and Y values are changed)

S-1-5-11 Authenticated users Contains authenticated users

After a user is successfully authenticated, Windows creates an access token for that user. Access token contains the SID of the user, SIDs of all groups in which the user is a member (including built-in and system groups), the SID identifying logon session, privileges assigned to the user and to user's groups, etc. If privileges assigned to the user or to one of the groups in which the user is a member change, or the user membership in some group changes, then the user must relogin in order for the changes to take affect [63]. When the user relogins, a new access token that contains updated information is created. Every process and thread executed on behalf of the user gets a copy of the user's access token. When a process or a thread request access to some securable object they present an access token to the system for the access control check.

Every securable object in the system has a security descriptor associated with it. The security descriptor describes who can have access to an object and what kind of access is allowed. It contains the following information: the SID of the owner of the object, the SID of the primary group of the owner (according to [61], primary groups in Windows access control model are used only for POSIX compliance), a system access control list (SACL), and a discretionary access control list (DACL).

DACL defines users and groups and whether they are allowed to access an object. If an object does not have associated DACL then everyone can access it [65]. DACL consists of a

36 number of access control entries (ACEs). The ACE contains the SID of the subject, the flag that shows if access is allowed/denied, and an access mask that defines access rights for that subject. If DACL for an object contains no ACEs (empty DACL) then no one can access the object [67]. Windows has the following access rights [66]:

 generic access rights: include READ, WRITE, EXECUTE, and GENERIC_ALL that is combination of all three

 standard access rights: include DELETE – the right to delete an object, READ_CONTROL – the right to read object's security descriptor, WRITE_DAC – the right to modify DACL, WRITE_OWNER – the right to change the owner of the object, and SYNCHRONIZE right.

 SACL access right: the rights to get or set SACL in the object's security descriptor

 object-specific access rights: for a example, the right to create files in a directory is FILE_ADD_FILE

SACL controls whether attempts to access an object are logged. ACEs in SACL specify which access attempt types and by which subjects should be logged. Both failures and successful attempts are logged. Most objects in the Windows system do not have SACL [61].

In the discretionary access control model an owner of an object defines access permissions for other users and groups. In Windows system the owner of an object and the system administrator have a full control over the object. When the object has empty DACL no one (even the owner) can access the object, but the owner can still modify access permissions [61]. However, if the DACL of the object contains ACE with the SID S-1-3-4 “OWNER_RIGHTS”, then implicit READ_CONTROL and WRITE_DAC rights of the owner are ignored. This mechanism was introduced in order to prevent users from modifying permissions for their own files [61].

When a process or a thread requests excess to a securable object, the system checks the provided access token against the DACL of the object considering the requested access type. ACEs in the DACL are checked sequentially for SIDs that match those in access token until access (everything that was requested) is granted or denied or the end of DACL is reached. It means that access is granted when one or more access allowed ACEs permit all requested access rights for any subset of SIDs in the security token of the principal [68]. Access is denied when the deny ACE, for one of the SIDs in the access token, that denies any of the requested access rights is encountered in the DACL [68]. If the end of the DACL was reached and there is some requested access right that was not allowed by ACEs, then access is denied.

Users of the Windows system have rights and privileges. A privilege is a right to perform system-related management operations like changing time, rebooting the system, loading drivers, etc. [69]. Thus, privileges differ from access rights that subjects have to securable objects. Privileges are held in the assigned access token whereas access rights are defined in the security descriptor of securable objects. It is important to distinguish user rights (logon rights) and access rights to securable objects. Logon rights are like privileges except the fact that they are used to allow a user to log on to the system, and privileges determine what a user can do after logon [61, 63]. Some of the logon rights are presented in the following table.

Table 3.1.1.3: Logon rights in Windows

Logon right Description

Access this computer from a network

determines which users/groups can logon via a network. By default this right is granted to everyone.

37 Allow log on locally defines who can interactively logon to the system via

connected terminal Allow log on through

Terminal Services

defines who can logon to a remote computer via Remote Desktop Protocol [63]

Deny access to this computer from network

defines for whom network logon is denied Deny log on locally defines for whom local logon is denied

Role-based access control

The Role-based Access Control (RBAC) is an alternative to the discretionary access control system that is used in Windows. Access to resources is based on a role. It means that privileges are assigned to roles. The role is an abstraction that reflects which operations and job functions a user can perform. When a user is assigned to a role he obtains privileges of that role. Windows Authorization Manager (AzMan) provides support for RBAC in Windows. Administrative tools allow to define role-based authorization policies against which access control check will be made.