Geoff Chappell - Software Analyst
SKETCH OF HOW RESEARCH MIGHT CONTINUE AND RESULTS BE PRESENTED
This old page from 2008 is now retired. Back then, this website had no place for it except among these miscellaneous Notes. I anyway meant it only as a quick write-up to stake an interest in a topic even if I never found cause to return to it. As it happens, I have returned to this topic many times since but left this page here, neglected. Now it is redone as ETW Security in the site’s extensive notes on kernel-mode Windows programming.
Event providers and loggers are securable WmiGuid objects. Access rights specific to WMI security are defined symbolically in WMISTR.H from the Windows SDK. Microsoft even describes some of them in documentation of the EventAccessControl function.
|Constant||Symbolic Name||Generic Mapping (ETW)||Generic Mapping (WMI)|
With one exception, each permission is also implied by one of GENERIC_READ, GENERIC_WRITE and GENERIC_EXECUTE. Even GENERIC_ALL just combines the generic read, write and execute permissions, and does not grant access to the NT Kernel Logger.
Permissions for particular loggers and providers are stored in the registry:
where guid is the string form (without braces) of a GUID that represents the provider or logger. The binary data is expected to be a self-relative security descriptor. Let it be stressed that this means a SECURITY_DESCRIPTOR_RELATIVE structure followed by all the SIDs and ACLs that it refers to, not a string in the Security Descriptor Definition Language (SDDL) such as used below.
The special value 0811c1af-7a07-4a06-82ed-869455cdf713 represents all objects that do not have their own permissions. It is defined symbolically as DefaultTraceSecurityGuid in EVNTRACE.H from the Windows SDK, but seems to be otherwise undocumented. Windows Vista is installed with the following security descriptor as this default:
It may help to have the corresponding access rights described in terms of symbolic constants from the Windows SDK:
|User or Group||Rights|
|Performance Log Users||WMIGUID_QUERY
These default permissions are presumably what Microsoft’s documentation has in mind when talking of Performance Log Users being able to control sessions. Note that although members of the Performance Log Users group have most of the defined permissions, they lack WMIGUID_SET, WMIGUID_READ_DESCRIPTION, WMIGUID_EXECUTE and TRACELOG_ACCESS_KERNEL_LOGGER.
If a valid security descriptor is not set for the 0811c1af-7a07-4a06-82ed-869455cdf713 value, the kernel falls back to the built-in WMI default:
Note that this provides no middle ground between having all access and nearly none:
|User or Group||Rights|
Both the installed default and the built-in default extend full control not just to the SYSTEM account and to Administrators but also to the LOCAL SERVICE and NETWORK SERVICE accounts. The security descriptors installed for some providers do not permit any access to anyone other than Administrators and the SYSTEM account. This shuts out the Eventlog service, which runs as LOCAL SERVICE in Windows Vista. A consequence in practice is that even a user with administrative privilege will encounter an error if trying to enable these providers through either the Event Viewer or the WEVTUTIL command-line tool, or through any tool that uses the Windows Event Log functions (such as EvtSaveChannelConfig). Whether this is intended is not known. A ready example is the Microsoft Windows Services Performance Diagnostic Provider.
WMI security can be managed programmatically through ADVAPI32 functions EventAccessControl, EventAccessQuery and EventAccessRemove, which are all documented. The last two operate directly on the relevant registry value, but the first works through the lower-level functions GetNamedSecurityInfo and SetNamedSecurityInfo.
A quirk should be noted. For a GUID that is registered, EventAccessQuery and GetNamedSecurityInfo produce the same security descriptor. If a GUID happens not to be registered, then EventAccessQuery fails (returning ERROR_FILE_NOT_FOUND) but GetNamedSecurityInfo produces the WMI default. This will typically not be the security descriptor that the kernel will apply if the GUID is used for Event Tracing. For that, ask EventAccessQuery about the DefaultTraceSecurityGuid.
The Reliability and Performance Monitor has a user interface for viewing and changing the security settings for providers and loggers. This tool is typically run as a Microsoft Management Console snap-in from the Administrative Tools menu. Among its Data Collector Sets are two sets of trace sessions. The Event Trace Sessions are all the loggers that are already started (well, all that are reported by the QueryAllTraces function). The folder named Startup Event Trace Sessions lists the loggers that are configured as AutoLoggers. The Properties dialog for any of these loggers lists the relevant providers and lets you manage security for each provider (via a Security button on the Trace Providers tab) and for the logger itself (via the Security tab).
This user interface is all I have found in the standard Windows package but surely cannot be all that Microsoft has coded. It has two significant defects.
First, it is not general. It does not let you browse the installed providers for their security settings before they are assigned to a logger. Neither does it let you browse the known loggers, such as shown in the Event Viewer. Though you can define a logger and assign providers to it, and set security for this logger and its providers, only by careful contrivance will your logger match one whose output you expect to see through the Event Viewer. There is perhaps an opportunity here for some third-party manufacturer of low-level maintenance gadgets.
Second, and this really is a coding error that may even make the interface unsafe to use, it misses two of the applicable permissions, namely WMIGUID_QUERY and TRACELOG_REGISTER_GUIDS. Where WDC.DLL tells ACLUI.DLL about the specific access rights that are available for these securable objects, its tables simply omit these two. This oversight persists at least to Windows Vista SP1. Where Windows Vista is reported to have problems of mass-market acceptance because of its focus on security, it ought at least be observed that some of what Microsoft has done about security is only half-baked.