The Windows security model requires that when a thread opens an object (such as a file, process, desktop, etc.), it must specify what types of actions it expects to perform on the object. The object manager invokes SRM (Secure Reference Monitor) to perform the access check according to the access requirements expected by a thread. If it allows this access, it assigns a handle to the process of the thread, and thus the thread or other process members The thread can perform further operations on the object through this handle. SRM is a component in Ntoskrnl.exe and works in kernel mode. It is responsible for: defining the data structure of the access token to represent a secure environment, performing access checks on objects, managing privileges, and generating all resulting security audit messages .
First, the security identifier SID
Windows uses SID to identify entities (security principals) that perform various actions in the system. Users have SIDs, local user groups, domain user groups, local computers, domains, domain members, and services.
For example, Windows uses a unique SID to identify an account and account group. After that, the operation performed by the account or account group (such as accessing a folder), Windows must verify its identity and confirm whether it has permission to operate. The SID of a local account or group is generated by the local security agency (LSA) on the computer and stored in the registry security area along with other account information; the SID of the domain account or group is generated by the domain security agency
(LSA on the domain controller) is generated and stored in Active Directory in the form of attributes of user or group objects.
The format of common SIDs is as follows (RIDs are not necessarily available):
procexp view SID:
Check the local service account SID in the registry :
The registry to view the local user account RID:
Generally, RID 500 is Administrator, 501 is Guest, and 503 is DefalutAccount. The RID of custom user accounts and groups starts from 1000.
In addition, Windows will predefine some accounts and groups, such as NT AUTHORITY \ Local Service S-1-5-19 , here you can view the common SID:
Second, mandatory integrity control (MIC, mandatory integrity control)
For the same user, open chrome.exe to download an unknown program and open word.exe, the two operations are different in risk, and obviously the process permissions should also be different; for this reason, Windows uses mandatory integrity control (MIC) to control the same user Access of different processes to secure objects.
The MIC mechanism consists of two parts: integrity level and enforcement policy. This mechanism is complementary to free access control and occurs before the free access control list (DACL) access check.
2.1. Integrity level
Both security subjects and security objects are assigned integrity levels, which are used to describe the access levels of visitors and respondents.
1. Process integrity level and token enforcement strategy ( TOKEN_MANDATORY_POLICY )
Each process has an integrity level in its access token, which is propagated according to the following rules:
In addition to the integrity level of the process, there is a mandatory strategy:
2. Object integrity level and system enforcement strategy
The security object has an integrity level in the system access control list (SACL) of its security descriptor
- In order to be compatible with older versions of window and to facilitate developers, all objects have an implicit integrity level of "medium"
- When a process creates an object, if the integrity level is not specified, the system will determine the integrity of the object based on the integrity in the process token. If the process integrity level is "medium" or higher, the implicit integrity level of the object is still "medium"; if the process integrity level is lower than "medium", it will explicitly match the token Objects at the integrity level.
Why can't the object inherit the creator's "high" integrity level? If the administrator disables UAC and creates an object, the process is at "high" integrity level, if the object also inherits "high" integrity level, when UAC is enabled again The administrator will not be able to modify this object.
- Objects can also have an integrity level explicitly set by the system or the object creator. When objects such as processes, threads, tokens, and jobs are created, the kernel will assign a displayed integrity level so that processes with the same integrity level under the same user cannot access or modify these objects.
In addition to integrity levels, security objects also have a mandatory policy:
You can use accesschk.exe -v to view the integrity level and enforcement policies of objects such as processes, files, and registry:
3. Access Token
SRM uses token objects to identify the security context of a process or thread. The most important content contained in the token is as follows:
1. Token source, describing the entity that created the token
2. The main token is still an imitation token, and the imitation level of the imitation token (described later)
3. Token ID, equivalent to token identifier, each token is unique.
4. Authentication ID, LSASS is for all tokens inherited from the same initial login token, and copies its authentication ID for the program to check whether the token and other tokens belong to the same login session.
5. Modify the ID. Whenever the characteristics of a token are modified, the modified ID will be refreshed.
6. Expiry time, token expiry time
7. Session ID
8. Various flags determine certain behaviors of UAC and UIPI mechanisms (described later)
9. Login session
10. Enforcement strategy, corresponding to the token enforcement strategy mentioned in the second part
11. The default main group and the default DACL, the default main group and the default DACL of the objects created by the process, so that it is not necessary to display and specify these information every time the object is created.
12. User account SID, account to which the process belongs
13. Group SID, which groups the user account belongs to
14. Restricted SID, mark this SID as deny-only, when access check is done later, only those access-denied ACEs are matched, and access-allowed ACEs are skipped, which is only used for denial.
15. Privileges (described later)
Mock token