[Windows] Windows Access Control Model

After the struggle in March, the judgment of OJProgramSecurity is still a headache for me. It takes almost half a month to solve this problem. Although no perfect solution has been found, I have finally learned how Windows security works. I will share my experiences in this regard.

 

The access control model in Windows is a basic component of Windows security. The access control model consists of two main components: access token and security descriptor, which are the attributes of the visitor and the accessed. Through the access token and Security Descriptor content, Windows can determine whether the visitor holding the token can access the object holding the security descriptor.

 

The access token is associated with a specific Windows account. When a Windows account is logged on, the system reads the information of the account from the internal database and generates an access token using the information. All processes started in the account environment will obtain a copy of this token. The thread in the process holds this token by default. When a thread wants to access an object or perform system management-related operations, Windows will use the token held by this thread for access check.

 

The security descriptor is associated with the accessed object. It contains the SID of the object owner and an access control list (ACL, access control list ), the access control list includes the DACL (Discretionary Access Control List) and SACL (system access control list). Currently, you do not know the exact translation of these two items, DACL is the most important security descriptor. It contains zero or more access control items (ACE, access control entry ), the content of each Access Control item describes how to allow or deny a specific account to perform specific operations on this object. SACL is rarely used. It is mainly used for system audit. Its content specifies that system logs are recorded when a specific account executes a specific operation on this object.

 

Now, we have roughly introduced the access token and security descriptor, but we still haven't talked about how they work together. To learn how they ensure the security of windows, you need to go inside them and see what is in it.

 

The access token mainly contains the following content:
The SID of the current Logon account, that is, the account Sid associated with the token;
List of account groups to which the current Logon account belongs;
List of restricted Sid (restricted Sid;
The list of the current Logon account and its associated account group permissions (privileges.

 

Sid (security identity) is an identifier of every account and account group in Windows. The administrator, users, and other accounts or account groups we usually see are identified by SID in windows. For example, a S-1-5-21-1004336348-1275210071-725345543-1003 is a complete Sid. Each Sid is unique in the same system.

 

Let's take a look at the specific ace content in the security descriptor:
Sid of a specific account or account group;
An access mask that specifies the specific access permissions, that is, the operations that can be performed on the object;
Indicates the ace type;
A set of BITs that indicate whether the Sub-object of the object to which the security descriptor belongs inherits the ace.

 

All the accessible objects have three types of ACE: Access-denied ace, access-allowed ace, and system-Audit ace. Access-denied Ace is used to deny account access, access-allowed Ace is used to allow account access, and system-Audit Ace is used in SACL.

 

When a thread tries to access an object, the system checks the token held by the thread and the DACL in the security descriptor of the accessed object. If the security descriptor does not contain DACL, the system will allow the thread to access the security descriptor.

 

If DACL exists, the system will traverse each ace in the DACL sequentially and check whether the SID in the ace exists in the thread token. Traversal ends when the following conditions are met:

 

The SID in an access-denied ace exists in the thread token, And the permissions in this ace are consistent with the permissions required by the thread. In this case, the system rejects the thread from accessing the object.
The SID in an access-allowed ace exists in the thread token, And the permissions in this ace are consistent with the permissions required by the thread. In this case, the system allows the thread to access the object.
The SID in all ace does not exist in the thread token. In this case, the system rejects the thread from accessing the object.

 

It is converted from msdn. the DACL of the object contains three Ace. The first ace rejects the Andrew account to read, write, and execute the object; the second ace allows all accounts in the account group A to write objects. The third ace allows any account to read and execute objects.

 

 

When thread a tries to access the object and traverses the DACL, it encounters the first ace that satisfies the preceding conditions. The traversal ends and thread a is denied access to the object, although the access token of thread A contains the SID of group A's account group and matches the second ace. Similarly, the third ace is not checked. The Analysis of thread B is the same, so it won't be too long here. It can be seen that the arrangement order of ACE is very important for the thread to access objects.

 

I mentioned a "restricted Sid list" when I introduced the access token. I have been confused for a long time and have never understood what it is. After some experiments, I guess its purpose. Although not necessarily true, I would like to explain it briefly here.

 

When an access token contains a list of restricted Sid, the system will only match the restricted Sid when traversing the ace, and ignore the remaining Sid in the token, that is, the other Sid is deleted from the access token.

 

In addition, there is a permission list in the token. the permission has nothing to do with object access, so it has nothing to do with security descriptors, Sid and so on. When a thread executes some management-related operations, the system checks whether the token of the thread contains specific permissions. If yes, the thread is allowed to execute the operation. Otherwise, the operation is rejected. To view the complete permission list, run gpedit. MSC and choose computer configuration-Windows Settings-Security Settings-local policy-User Privilege assignment ".