Ensuring Security in Windows-Based Services | MCAD/MCSD: Visual Basic .NET XML Web Services and Server Components Study Guide

Securing Windows-based services involves the standard set of security options that you learned about in Chapter 9, “Overview of Security Concepts.” You need to make sure that users are authenticating against your service and are authorized to do the minimum needed to accomplish the task at hand. Visual Studio .NET’s role-based security makes this easier to accomplish by grouping users under common functions. You will also want to take advantage of code access security to make sure the code running is trusted and limited to only what it needs to do; that way if someone finds a hole in you application that enables them to elevate their permissions, your code can do no more than it is allowed to do. You also should remember that data you receive should not be trusted and should be verified to make sure it is what your application expects. You can use regular expression as a powerful tool to accomplish this task. Data you send over a network is also potentially vulnerable to snooping. You should consider using encryption on any sensitive data sent over a network (after all, the network protocol analyzer (sniffer) Ethereal is a free download).

In addition to these generic principles, each type of application can have some specific security considerations, which you will look at in this section.

Securing Windows Services

A Windows service runs with a service account. This account is used by the service when accessing the file system or database services, or even when logging onto another machine remotely. You need to make sure that you don’t elevate the permissions of the service by linking it to an account that has more permissions than the service needs.

For example, you could create a service that looks for a file in a specific directory and then updates a database table with the information in the file. If you set this up to use an account with Administrator privileges, the service could have Full Control permissions on any directory on the whole computer and maybe have access to many more databases and the accompanying tables and stored procedures and commands (such as the Data Definition Language commands of DROP, CREATE, and ALTER). This service would need permissions only to read from a directory and write to a specific table in a database, no more, no less. You should then create an account and give it these permissions. Otherwise, your service might have a bug in it, and a user might accidentally or purposely exploit the bug. If you used the least privileges principle, you could avoid extensive damage.

Note

You should also use declarative attributes to state which types of permissions your code is requesting, as discussed in Chapter 9.

Securing Serviced Components

COM+ applications use a role-based security mechanism to simplify the security features provided by DCOM and authenticated Remote Procedure Call, which COM+ is built upon. The COM+ role-based security model is one in which the individual identity of the user is not important, but the logical role that the user can assume is important.

There are three levels at which you can apply role-based security to a COM+-based component: component, interface, and method. The role you apply at one level automatically propagates to the lower levels. For example, if you assign a role to the component level, then members of the role can call into any interface and method on the component. You would need to add the role to the interface or methods for more fine-grained control.

You can implement role-based security on a serviced component declaratively with various attributes that are contained in the System.EnterpriseServices namespace. You just need to apply them at the proper level in your code.

You can also check security imperatively in a serviced component. This is useful if you require doing security checks at a finer level than the method. You use two methods to use imperative security: IsCallerInRole and IsSecurityEnabled.

The IsCallerInRole method has the following signature:

IsCallerInRole(String_Value)

This is used to check whether the current COM+ security context is in the role that is passed to the method. The String_Value is the name of the role allowed to perform the action. It is part of the ContextUtil object in the System.EnterpriseServices namespace.

The IsSecurityEnabled method will test whether security is turned on for this COM+ application. The administrator could turn off security by using the Component Services tool. If security is turned off, then IsCallerInRole will always return True.

The following is an example of imperative security:

Public Function GetSSN(ByVal PatientID As Integer)As String If Not ContextUtil.IsSecurityEnabled Then    Return "Must have security " & "enabled to call this method" End If If ContextUtil.IsCallerInRole("AdminManager") Then   Return SSN End If End Function

The .NET Framework and COM+ role-based security models use different mechanisms and are independent of each other. COM+ uses the Windows token to identify the user. The Windows token and the COM+ role are associated with the context of the serviced component through a security descriptor. The .NET Framework associates the security context with the current thread. This context is based on the Identity and Principal objects and does not necessarily rely on a Windows token. The WindowsIdentity and WindowsPrincipal objects are associated with a Windows token. This means that if you use the .NET Framework role-based security, the security context is not available to the serviced component. If you use COM+ role-based security, the security properties of the serviced component are not available to the .NET assembly outside of the current process or newly created threads without extra work on your part.

In Exercise 10.11, you will configure a serviced component to use role-based security.

Exercise 10.11: Configuring Serviced Components to Use Role-Based Security

Open the project called Exercise 10.4 in Visual Studio .NET.
Add the following attributes just above the Public Class DynReg statement:
```
<ComponentAccessControl> _ <SecureMethod> _ Public Class DynReg
```

Add the following attributes just above the Message function:

<SecurityRole("GuruDeveloper")> _ Public Function Message() As String

Add the following assembly-level directives to the AssemblyInfo.vb file in the project:

<assembly: ApplicationAccessControl(AccessChecksLevel= _ AccessChecksLevelOption.ApplicationComponent)> <assembly: SecurityRole("GuruDeveloper")> <assembly: SecurityRole("JustADeveloper")> <assembly: SecurityRole("User")> <assembly: SecurityRole("SeniorManager")>

Build the solution.
Install the component in the GAC by using the following command at a Visual Studio .NET command prompt:
```
gacutil -i path_to_MyDocuments\Visual Studio ~CA  Projects\DynReg\bin\DynReg.dll
```

regsvcs path_to_MyDocuments\Visual Studio ~CA  Projects\DynReg\bin\DynReg.dll

Verify that the component is installed by opening the Component Services tool.
Expand Component Services, Computers, My Computer, COM+ Applications.
Right-click DynReg and choose Properties.
Click the Security tab and verify that Enforce Access Checks For This Application is selected and that the security level is set for the process and component level.
Click OK to close the Properties dialog box.
Expand the DynReg application, the Components folder, and the DynReg class, IMMessage interface.
Right-click the Message method and click Properties.
Click the Security tab and verify that the GuruDeveloper role is associated with the method.
Click the OK button to close the dialog box.
Expand the Roles folder under the DynReg application and verify the roles were added that you specified in the SecurityRole attributes of the file.

Securing .NET Remoting Objects

Security can become an issue with .NET Remoting objects when the object is moved into another application domain with lesser permissions or especially when the object is moved to a different server. For example, the object might work fine opening secure files and reading them on your workstation because they are being loaded in the same executable (for example, client.exe) and thus are running under your security context. But when you move the object to a server and try the same thing through remoting, it will fail. This happens because the server is not running in the client’s security context that is authorized to access the files.

You should realize that this will be the case with Remoting objects that are running in a different process or server. What you need is for the server to impersonate the client. You need to consider a mechanism to authenticate the user, impersonate the user, and make sure the data that is moving between the server and the client is secure. (You might interact with the Secure Support Provider Interface APIs of Windows in conjunction with the CrytoStream objects of .NET to do this.) Otherwise, you can also use the services provided by IIS for authenticating the user and encrypting the traffic over the network as we discussed earlier in the “Deploying a .NET Remoting Object” section to make this easier.

If the .NET Remoting object is part of a Windows service or COM+ application (which it usually is), you should follow the security procedures already outlined for each of these services above.