Microsoft KB Archive/823915

= INFO: Code access security for Windows Management Instrumentation (WMI) overview =

Article ID: 823915

Article Last Modified on 5/16/2007

-

APPLIES TO


 * Microsoft Windows Management Instrumentation 1.5
 * Microsoft Visual Studio .NET 2003 Academic Edition
 * Microsoft Visual Studio .NET 2003 Enterprise Architect
 * Microsoft Visual Studio .NET 2003 Enterprise Developer

-



This article discusses some basic issues about security to consider when you work with Windows Management Instrumentation (WMI) in managed code.

This article discusses the following topics:
 * Access to code
 * Access to WMI data and events
 * Provision of data and events
 * Specification of the users who can provide data and events



Access to code
The WMI service is an unmanaged component that permits different operating system sources to access different information. When managed code accesses WMI, the code that is accessing WMI must be fully trusted by the system. Therefore, code that uses or provides WMI data and events must have permission to access the unmanaged code.

For more information about this permission, see the &quot;Security&quot; topic in the .NET Framework SDK documentation.

Access to WMI data and events
WMI uses every feature of Windows user-based security to help secure access to the data and events that are provided through WMI.

The data and events that are provided to WMI are organized in a namespace hierarchy. For example, the root\cimv2 namespace that is on the computer contains all the management information that is provided by the operating system. The following is a typical namespace where an instrumented application publishes data and events:

root\ \ 

The role of the security descriptor (SD)

 * Each WMI namespace has a security descriptor (SD) attached to it.
 * The SD defines the Windows users and groups who are permitted to access the information that is available in that namespace.
 * This SD is set to a certain default; you (or an administrator) can change this SD by using the WMI Control Microsoft Management Console (MMC) snap-in that is included with the OS.

Default access permissions
Following are the default access permissions:
 * Everyone, Local Service, Network Service - Permission to read data, to write data, and to run methods for providers on the local computer. This does not include writing new schema or installing new providers.
 * Administrators - Full Control, both locally and remotely.

For more information about the WMI security mechanisms, see the WMI Platform SDK documentation, or visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/aa392291.aspx

Provision of data and events
WMI also provides the means to define who can publish data and events to the system. The System.Management.Instrumentation classes use the decoupled provider architecture, where the provider lives in the process of the instrumented application and where the lifetime of the provider is controlled by the application. This architecture is different from regular providers; regular providers are loaded and unloaded by the WMI service.

Decoupled providers are subject to the following security restrictions:  By default, a decoupled provider is not permitted to impersonate the calling client.

Calls that are made from WMI to a decoupled provider are typically made by using an Identify security token. In this way, the provider can identify the caller but cannot impersonate the caller. By default, registration of any provider with WMI requires the user who installs the application to be an administrator. Therefore, only an administrator can register an instrumented application as a provider of management data and events. The developer of an instrumented assembly can define an SD that identifies the users and groups who will be permitted to publish management data and events from this assembly.

In the System.Management.Instrumentation classes, this SD can be passed in security descriptor definition language (SDDL) format as an argument to the instrumented attribute. The SD is then used when the application is registered with WMI. Additionally, the SD can be changed by an administrator after deployment of the application.

By default, the following users and groups are permitted to publish data and events:  Administrators Local System Local Service Network Service</li> Batch Logon</li></ul>

To change this default, you can specify an alternative SDDL setting for your application.

For more information, see the “Specifying users to provide data and events” section in this article.</li></ul>

Specification of the users who can provide data and events
To change the default set of users who are permitted to either fire events or expose data from a managed application, use either of the following methods:
 * Method A - Modify the SecurityDescriptor property of the InstrumentedAttribute class
 * Method B - Modify the SecurityDescriptor property of the WMINET_ManagedAssemblyProvider instance

Method A - Modify the SecurityDescriptor property of the InstrumentedAttribute class
At development time, you can change the default SD that is assigned to the provider of this application by specifying the SecurityDescriptor parameter to the instrumented assembly attribute. <ul>  On Microsoft Windows 2000, the default SD is as follows: O:BAG:BAD:(A;;0x10000001;;;BA)(A;;0x10000001;;;SY) (A;;0x10000001;;;LA)(A;; 0x10000001;;;S-1-5-3) (A;; 0x10000001;;;S-1-5-6) </li>  On Microsoft Windows XP or later, the default SD is as follows: O:BAG:BAD:(A;; 0x10000001;;;BA)(A;; 0x10000001;;;SY)(A;; 0x10000001;;;LA) (A;; 0x10000001;;;NS)(A;; 0x10000001;;;LS)(A;; 0x10000001;;;S-1-5-3) (A;; 0x10000001;;;S-1-5-6) In this code, the  placeholder is BATCH, and the   placeholder is SERVICE. </li></ul>

When you grant a new user permission to provide instrumentation, you must append the ACE string of the new user to the default SD. If you only specify the new SD in the SecurityDescriptor parameter, the default SD is overwritten.

For example, to add the Power Users group to the list of permitted users and to the default SD on Windows 2000, provide the following SDDL string: O:BAG:BAD:(A;; 0x10000001;;;BA)(A;; 0x10000001;;;SY)(A;; 0x10000001;;;LA) (A;; 0x10000001;;;NS)(A;; 0x10000001;;;LS)(A;; 0x10000001;;;S-1-5-3) (A;; 0x10000001;;;S-1-5-6)(A;;0x1;;;PU) In this string, &quot;(A;;0x1;;;PU)&quot; (at the end of the string) is the new ACE string for permitting Power Users to provide instrumentation. WMI requires you to have the least significant bit set (that is, 0x1) for the access rights value in an ACE string.

Note At development time, you will probably be restricted to specifying only well-known users or groups. This restriction is because you cannot specify users or groups that are specific to a specific deployment of your application in a specific environment. When your application is installed, you may require the ability to change this setting; you might use a custom installation step that changes this setting programmatically.

Method B - Modify the SecurityDescriptor property of the WMINET_ManagedAssemblyProvider instance
When a managed instrumented application is registered with WMI, a new instance of the WMINET_ManagementAssemblyProvider class is generated and stored in the application namespace in the WMI repository.

To modify the SecurityDescriptor property of the WMINET_ManagedAssemblyProvider instance, follow these steps:
 * 1) Determine the specific users or groups that you want to permit or deny access.
 * 2) Find the security identifiers (SIDs) for these users or groups.

To find the SID property of the Win32_UserAccount instance for a particular user, or to find the Win32_Group for a particular group, use the Wbemtest.exe program.
 * 1) Use these SIDs to construct an SDDL string (as shown earlier in this article).
 * 2) Use the System.Management functions to change the setting.

This setting is defined in WMI as a property that is named SecurityDescriptor on an instance of the WMI class that is named WMINET_ManagedAssemblyProvider.

If a user is not permitted to provide instrumentation, and if the user tries to fire events or to publish instances, the user receives the following error message:

Access Denied (0x80041003)

<div class="references_section">