[Windows Kernel Principle and Implementation] Reading Notes (5)

Event tracking (ETW)

Windows provides a unified mechanism for tracking and recording events, called ETW. User-Mode Applications and kernel-mode drivers can use ETW to record events. ETW is an event recording mechanism directly supported by the kernel. In its framework structure, there are three components:

• Controller ). Starts, stops, or configures event record sessions.
• Provider ). Registers its own event classes with ETW and accepts controller commands to start or stop the recording process of the event classes they are responsible.
• Consumer ). It is responsible for reading the event data they want and selecting one to live multiple record sessions. They can receive data in the ETW buffer in real time or event data in the log file.

Windows has a built-in kernel logger as the ETW provider, which is used to record events of the kernel and core drivers. This kernel logger is implemented by the WMI (Windows Management Instrumentation, Windows Management Specification) device driver. Its driver name is "wmixwdm ".

WMI is an implementation of the industrial standard WBEM (Web-Based Enterprise Management. The kernel logger is an event provider that has a predefined guid, namely, the kernel variable systemtracecontrolguid. The kernel logger supports multiple event classes and uses flag to indicate whether to record a certain type of events. These events are further divided into eight groups, each of which is described with a mask (29 BITs. The global group mask of the system is defined by the global variable perfglobalgroupmask.

Buffer management is one of the important responsibilities of the WMI driver.

Microsoft provides a performance tool, xperf, which is both a controller and a consumer. Xperf uses the I/O interface (ntdeviceiocontrolfile function) to communicate with the WMI driver. Windows API provides the event tracking API (in the advapi32.dll Module). Therefore, the user-mode application can easily manipulate and control the WMI driver.

Security Management

• SRM (Security Reference Monitor) is responsible for performing security access checks on objects, managing user privileges, generating security audit messages, and defining an access token data structure to represent a security environment.
• Winlogon is responsible for responding to SAS (security attention sequence) and managing interactive login sessions. When a user logs on to the system, Winlogon creates an initial process and then creates a shell process.
• LSASS (Local Security Authority Subsystem) is responsible for security policies of the local system. It also authenticates the user's identity and sends security audit messages to System Event Logs.
• The Sam (Security Account Manager) database contains local users and user groups, as well as their passwords and other attributes. Located under the Registry HKLM \ SAM, only access from the local system account is allowed.
• The LSA policy database contains information about the current system, which is also stored in the registry and is located under HKLM \ Security.

In the Windows security model, Winlogon is responsible for system logon, including user identity authentication. LSASS is responsible for managing local system security policies and notifying SRM in the kernel of these policies. In the kernel, SRM is responsible for implementing object-based access control and global security policies of the system.

SRM and LSASS are crucial. they communicate with each other through LPC. Their LPC links are established during system initialization. Once a two-way LPC connection is established, their LPC ports no longer accept any other connection requests.

The autonomous access model of Windows is integrated with the object manager. Each object type defines a security method, which returns the security information of an object. Before a thread can access an object, it must open the object and obtain a handle pointing to the object. In this model, each thread has a security environment, and the most important information is an access token, representing a login of the user of the thread; each object has an autonomous access control list (ACL) that specifies who is allowed to access the object and who is denied to access it. To access an object, a thread can use the security environment of the process to which it belongs, rather than the security environment that runs as another account. This is called impersonation ). Other threads in the same process can also use the obtained handle to access this object.

A token represents the topic used by SRM. It describes a user's logon. It is created after the Winlogon process authenticates the user identity.

In Windows, the privilege is identified by a luid object. luid represents a local unique identifier (locally unique identifier) consisting of two long members.

The internal functions of SRM are the functions prefixed with SEP.