Page #85 (Chapter 7. Security)

< BACK  NEXT >

[oR]

The COM+ Security Model

Although COM is supposed to be platform-independent, it is not possible for us to completely ignore the security model of the underlying operating system. Consequently, before we delve into a detailed discussion of the many issues concerning the COM+ security model, I shall review the basics of the Windows NT security system. However, I will consciously try to keep the details to a minimum and cover only those aspects that are relevant to our current discussion.

Windows NT Security System Basics

Under Windows NT (Windows 2000 is based on NT technology), each user or group is referred to as an account ^[1] and is uniquely identified by a security identifier, or SID. Each time an account is added to the system, the system generates an SID and assigns it to the new account. Built-in accounts such as LocalSystem and Administrator have predefined SIDs.

^[1] NT 4.0 introduced a new term, trustee, to represent an account.

Windows NT is also a highly secure operating system. Most of the objects in the system such as NTFS files, registry keys, processes, threads, etc., can be configured so that they are accessible only by selected accounts. Such objects are referred to as securable objects. Each securable object has a security descriptor (SD). Among other things, a security descriptor contains:

• An owner SID that identifies the current owner of the object. An owner can always access the object.

• A discretionary access list, or DACL, that determines which accounts can access the object and which accounts are specifically denied access to the object.

The DACL is at the heart of NT security. The entries in this list are called access control entries (ACEs). Figure 7.1 shows the layout of the ACE.

Figure 7.1. The layout of the ACE.

An ACE consists of three parts: an ACE header, a SID, and an access mask. The ACE header determines whether the access is allowed or denied. The SID identifies a single user or group (account) for which the access is allowed or denied. The access mask determines the level of access that is allowed or denied. For example, the DACL for an NTFS file can contain an ACE entry that indicates that user Smith is denied access for writing to the file. Figure 7.2 shows an example of such a DACL.

Figure 7.2. An example of a DACL.

The order of ACE entries in the DACL is important. For example, consider the case where smith belongs to a group called hackers. Let s say the DACL for a file contains two ACES: one that denies access to the hackers group and the other that allows access to smith. If the latter ACE is present before the former ACE in the DACL, user smith gets the access to the file. Just reversing the order would deny access to smith.

Also note that an SD may not contain a DACL at all, indicating that the object does not need any protection. On the other hand, an SD with an empty DACL indicates that no one is allowed access to the object. Be careful not to confuse these two cases.

Only the owner of a securable object can access its SD to add or delete ACEs.

How does the system determine if a process can access a securable object? The key lies in another NT entity the access token.

When you log on to an NT system, the system gives you an access token. Among other things, the access token contains:

• The user SID, identifying who you are.

• The list of each group that you belong to.

Under NT, each process runs within the security context of a user. The process gets attached to the access token of the account that created the process (by calling CreateProcess) or the access token of the account that was passed as a parameter to CreateProcessAsUser.

When the process accesses any securable object, the system calls match the accounts from the process access token against the entries in the DACL of the securable object and determine if the access should be allowed or denied.

To be more precise, it is not the process but a thread within the process (either the primary thread or any other spawned thread) that accesses the securable object. Under NT, however, the system provides the ability to execute a thread in a security context different from that of the process that owns the thread. This is called impersonation. So, when a thread accesses a secured object, the system checks if the thread is under impersonation. If it is, the system uses the access token of the impersonating user. Otherwise, the access token of the owner process is used for an access check.

A process itself is a securable object, and therefore has its own security descriptor. By default, its DACL specifies access only to the user represented by the access token of the process. If other users must access the object, the owner of the process can add ACEs to the DACL that grants access to a group of users.

I have included a program on the CD that dumps the security descriptor of a process. This code can be slightly modified to dump the security descriptor for any securable object.

The most visible part of the security system is the password. Giving away the password will compromise the security of the whole system. When sensitive data such as passwords are transferred over the wire, the user should inform the underlying transport provider to take extra precaution to ensure data security.

Do not give out your passwords.

For more information on NT security, read Marshall Brain s Win32 System Services [Bra-94]. Another good reference to look at is Professional DCOM Programming by Richard Grimes [Gri-97].

Now, let s look at various security issues that COM addresses.

Security Issues Under COM

Activation Control

We need to ensure that sensitive applications cannot be launched by just anyone. For example, let s say a company has developed a component to review and change employee salaries. It makes sense that only the managers should be able to launch such a component.

COM provides a mechanism to specify who is permitted to launch the application. This is referred to as activation control.

An administrator chooses accounts (users or groups) that are allowed or denied permission to start the application on the local computer.

The administrator can also define system-wide launch permissions used by COM when an application does not provide its own launch permissions.

An activation control setting is meaningful only for classic COM applications. COM+ applications use a different mechanism called role-based security that will be described later.

Access Control

Preventing unauthorized persons from launching the application isn t enough. A malicious user, for example, can still connect to an already launched application and access its services.

To solve this problem, COM provides a mechanism to control access to the component s objects. The access control determines who is permitted to access the component s objects.

Similar to launch permission settings, an administrator selects users or groups that are allowed or denied permission to access the component s objects.

The administrator can define system-wide access permission used by COM when an application does not provide its own access permissions.

The access control setting is meaningful only for classic COM applications. COM+ applications use role-based security.

Authentication Control

When a client makes a connection to the server, the server must be able to verify that the client is who it says it is. Otherwise, for example, an employee could fake himself as a manager, access the employee salary component that we talked about earlier, and give himself a nice little raise.

The process of identifying the caller is called authentication. In association with the underlying security support provider (SSP), COM can authenticate the caller. SSPs are covered later in the chapter.

Authentication also provides data security. When a client calls a method on a remote server object, the method call parameters get transmitted over the wire. To protect this data from the hackers, authentication can be set at various levels, encryption being one such option. These levels are indicated by RPC_C_AUTHN_LEVEL_xxx constants, defined in the SDK header file <RpcDce.h>.

The possible authentication levels from lowest to highest security along with their description, are shown in Table 7.1.

Table 7.1. COM+ Authentication Levels

Level	Constant	Description
Default	RPC_C_AUTHN_LEVEL_DEFAULT	The underlying SSP provides the default value.
None	RPC_C_AUTHN_LEVEL_NONE	No authentication.
Connect	RPC_C_AUTHN_LEVEL_CONNECT	Authenticates the client only when the client first connects to the server.
Call	RPC_C_AUTHN_LEVEL_CALL	Authenticates the client at the beginning of each remote call.
Packet	RPC_C_AUTHN_LEVEL_PKT	Authenticates that the data is received from the expected client.
Packet Integrity	RPC_C_AUTHN_LEVEL_PKT_INTEGRITY	Authenticates and verifies that data has not been tampered with in transit.
Packet Privacy	RPC_C_AUTHN_LEVEL_PKT_PRIVACY	Method call parameters are encrypted before transmission. The server authen-ticates, verifies, and decrypts the data.

Note that while each successive authentication level adds more security, it is done at the expense of decreased performance.

Identity Control

The identity control specifies the security credentials under which the component will execute. This could either be the security credentials of the interactive user (the user who is currently logged on to the computer), or a specific user account configured for this purpose.

An application is launched under the security context of the specified identity. This security context is used when the application tries to access resources, such as files or databases, or makes calls to other applications.

There are two important things to keep in mind when specifying the identity:

• If the application is set to run under the interactive users identity, the server will fail to run if there is no interactive user logged on to the system. While this is an extremely good feature for debugging an application, you should generally avoid using an interactive users identity for production code.

• The COM SCM calls Win32 APIs LogonUser and CreateProcessAsUser to launch the COM server using the specified account. Therefore, the account specified should have a Log on as a Batch Job privilege. Otherwise, activation requests will fail.

Sometimes it is desired that the server use the client s credentials during the method call to access a local resource. COM provides a mechanism to enable such impersonation during the method call.

Sometimes it is also desirable for the server to impersonate the client s security context when accessing a network resource or making outgoing calls to other servers (on other machines). This is called delegation. With the help of the underlying SSP, COM can support delegation.

The SDK defines each impersonation level by using RPC_C_IMP_LEVEL_xxx constants. Table 7.2 describes each impersonation level.

Table 7.2. COM+ Impersonation Levels

Level	Constant	Description
Default	RPC_C_IMP_LEVEL_DEFAULT	The underlying SSP provides the default value.
Anonymous	RPC_C_IMP_LEVEL_ANONYMOUS	The client is anonymous to the server. The server cannot obtain the client s identification information nor can it impersonate the client.
Identify	RPC_C_IMP_LEVEL_IDENTIFY	The server can obtain the client s identification information and can impersonate the client to do ACL checks.
Impersonate	RPC_C_IMP_LEVEL_IMPERSONATE	The server can impersonate the client. While impersonating, the server can access only those resources available on the server s machine.
Delegate	RPC_C_IMP_LEVEL_DELEGATE	The server can impersonate the client. The server can access network resources as well as make outgoing calls on the client s behalf.

Impersonation levels can also be used to protect the client from untrustworthy components. From the client s point of view, anonymous-level impersonation is the most secure, as the component can neither obtain any client credentials nor act on its behalf. With each successive level, a component is granted further liberties with the client s security credentials.

A few points to note about the impersonation levels:

• RPC_C_IMP_LEVEL_ANONYMOUS is not supported for remote calls. If specified, the impersonation will automatically be promoted to RPC_C_IMP_LEVEL_IDENTIFY.

• RPC_C_IMP_LEVEL_DELEGATE is not supported by Windows NT LAN Manager SSP (NTLMSSP). Kerberos SSP supports it.

• Impersonation level and authentication levels are largely independent of each other. However, to impersonate a client, the client has to be authenticated. Therefore, authentication level RPC_C_AUTHN_LEVEL_NONE cannot be used when an impersonation other than anonymous is desired.

• RPC_C_IMP_LEVEL_IDENTIFY is the default impersonation level when the OS is first installed.

Role-Based Security

Under COM+, roles provide a flexible and extensible security configuration model. A role is a symbolic name that identifies a logical group of users that share the same security privilege. This is conceptually similar to a user group in Windows NT (or Windows 2000); the difference being that a user group is global across a Windows NT domain, while roles are configured for specific COM+ applications.

When a COM+ application is deployed, the administrator can create certain roles (for the application) and bind those roles to specific users and user groups. For our salary component example, the administrator can create roles such as Managers and Employees and bind specific users (or user groups) to the roles. The administrator can then specify which role(s) can access the application. The administrator can fine-tune the access at the percomponent, per-interface, or even per-method level.

Essentially, roles provide protection for the code; they control access to methods that can be called by clients of a COM+ application. Role membership is checked whenever a client attempts to call a method exposed by a component in an application. If the caller is in a role assigned to the method it is calling, the call succeeds. Otherwise, the call fails and returns E_ACCESSDENIED.

Security Service Providers (SSPs)

Why does COM need its own security model? Windows is considered to be a secure operating system platform. Why can t COM components simply take advantage of that security model?

COM could have used Windows security model. However, COM requires a security model that can be supported on all platforms on which COM+ services are available.

Moreover, COM s dependency on RPC binds it to use many features of RPC security infrastructure.

The solution was to define a higher-level abstraction one that is based on the security provided by the operating system as well as the underlying RPC security mechanisms. This higher-level security model insulates (or tries to insulate) component developers from the specific security mechanisms so that components can benefit from newer security services without needing to change the code.

To obtain such a flexible security model wherein newer security services can be availed automatically, COM defined an API set, the Security Support Provider Interface (SSPI), that isolates everything the user sees from the systems that actually handle security.

A vendor can develop a DLL that implements SSPI. This DLL is referred to as a Security Service Provider (SSP). Though the vendor has to implement SSPI, it is free to use whatever mechanism it wants to enforce security.

Figure 7.3 shows the security architecture in COM+.

Figure 7.3. COM+ security architecture.

Prior to Windows 2000, only one SSP was available NTLMSSP. This SSP uses the NTLM authentication protocol that employs a challenge-response mechanism to authenticate clients. In the challenge-response mechanism, the server issues a challenge that consists of sending some data to the client. The client uses an encoded version of the user s password to encrypt this data. This encrypted data is then sent back to the server. The server decrypts the data and compares it with the original data. If the data is identical, the user is authenticated.

Note that the user s password is never sent across the network using NTLMSSP. For this reason, the server cannot use delegation to access network resources or to make outgoing calls to servers on other machines.

Windows 2000 offers a newer SSP that implements the Kerberos v5 network authentication service. NTLMSSP is still available under Windows 2000. However, Kerberos SSP is the default SSP.

Kerberos is a more sophisticated authentication protocol than NTLM, and supports features such as mutual authentication (client and server can both authenticate each other) and delegation of security information from one machine to another. For an in-depth discussion of the Kerberos security protocol, see David Chappell s article on Kerberos [Cha-99]. For our discussion, it is relevant to know that Kerberos SSP supports delegation while NTLMSSP does not.

The client and the server applications have to choose a specific SSP to communicate. In a mixed environment where some machines only have NTLMSSP and others have Kerberos SSP, it becomes problematic to programmatically choose an SSP. To solve this problem, Microsoft RPC provides a pseudo-SSP called the Simple GSS-API Negotiation Mechanism (Snego) SSP. Snego SSP does not provide any actual authentication feature. It just helps applications select a real SSP.

Besides the above three SSPs, Windows 2000 RPC supports many other SSPs. Each SSP offers its service in the form of what is called a package. Each package is identified by a specific RPC_C_AUTHN_xxx constant. Table 7.3 describes some of those security packages.

Table 7.3. Security Packages In Windows 2000

Description	Constant
No authentication	RPC_C_AUTHN_NONE
DCE private key	RPC_C_AUTHN_DCE_PRIVATE
DCE public key	RPC_C_AUTHN_DCE_PUBLIC
Snego	RPC_C_AUTHN_GSS_NEGOTIATE
NTLM	RPC_C_AUTHN_WINNT
Kerberos	RPC_C_AUTHN_GSS_KERBEROS
Microsoft SChannel	RPC_C_AUTHN_GSS_SCHANNEL
Microsoft MSN	RPC_C_AUTHN_MSN
COM+ security blanket negotiation to pick a default	RPC_C_AUTHN_DEFAULT

The list of packages installed on a system can be obtained using EnumerateSecurityPackages API. The API also returns the capabilities of each package. The CD contains a program, EnumSSP, that will dump the information for each installed SSP on the local machine.

A security package is also referred to as the authentication service. ^[2]

^[2] Technically, an SSP provides a security package. However, for most intents and purposes, an SSP, a security package, and an authentication service are one and the same.

Some SSPs, such as DCE SSP, are capable of using an authorization service to perform authorization checking. The SDK defines RPC_C_AUTHZ_xxx constants for authorization services. They are listed in Table 7.4.

Table 7.4. Authorization Services

Constant	Description
RPC_C_AUTHZ_NONE	No authorization.
RPC_C_AUTHZ_NAME	Authorization is based on the client s principal name.
RPC_C_AUTHZ_DCE	Authorization is based on the client s DCE privilege attribute certificate (PAC) information.
RPC_C_AUTHZ_DEFAULT	The default authorization service for the current SSP is used.

A server can specify the authorization service to use. However, as the most commonly used SSPs, NTLM and Kerberos, do not utilize any autho-rization service, the server typically specifies RPC_C_AUTHZ_NONE (or RPC_C_AUTHZ_DEFAULT that results in RPC_C_AUTHZ_NONE) as the authorization service.

Security Blankets

Under COM, the client specifies some security settings and the server specifies some settings. The collection of parameters that govern how security is handled between the client and the server is called the security blanket. A security blanket basically consists of the following parameters:

• The authentication service, that is, the security package to be used (Table 7.3).

• The authorization service to be used (Table 7.4).

• The principal name of the client.

• The authentication level to be used (Table 7.1).

• The impersonation level to be used (Table 7.2).

• The privileged information of the client application.

• Various authentication capabilities such as mutual authentication and cloaking. These capabilities are defined using the EOAC_xxx constants provided by the SDK (covered later).

While most parameters are specified exclusively by either the client or the server, there are some parameters that can be specified by both the client and the server. To select the appropriate settings, COM+ undergoes a negotiating process appropriately called the security blanket negotiation. The security blanket negotiation occurs when COM+ first instantiates a proxy. During the negotiation, COM picks up an authentication service that is available to both the client and the server. COM+ also chooses an authorization service and principal name that works with the selected authentication service. For the authentication level, COM+ uses the higher level of the client-side and server-side settings. The impersonation level is the one specified by the client. The server cannot specify the impersonation level. However, remember that the server itself can act as a client to another server, in which case it gets to specify all the client-side settings.

Once the default security blanket is computed, its values are assigned to the newly created proxy. These new values affect all calls made on the proxy, that is, until the client overrides the value programmatically by calling the IClientSecurity::SetBlanket API (covered later).

Now that we understand the security issues involving COM and the security model provided by COM, let s examine how we can explicitly specify various security settings.

In general, COM+ provides reasonable values for the default security setting so that an application can be developed and installed without considering any security aspects. However, there are situations when the default values are not adequate and you have to explicitly specify the security settings.

COM+ security settings can be neatly subdivided into two groups: declarative security and programmatic security. Declarative security can be used to override the default security. It reduces the amount of code that you have to write. For a finer control (and more pleasure for us geeks), you can handle security programmatically, thereby overriding both the default and the declarative security settings.

Let s begin by examining the declarative security.

< BACK  NEXT >