DSS Node Security Model

Glossary Item Box

DSS User Guide: DSS Security Configuration File

Windows Security: Security Identifiers | Authenticode Signing a DLL

.NET Framework Developer's Guide: Code Access Security | Code Access Security Policy Tool (Caspol.exe) | .NET Framework Configuration Tool (Mscorcfg.msc)

Microsoft Robotics Developer Studio

Send feedback on this topic

DSS Node Security Model

The security model for a Decentralized Software Services (DSS) node is comprised of three parts: authentication, service assembly loading, and network access permissions. The effect of each of these is as follows:

• Authentication: When Authentication is enabled on a node, all incoming transport connections require NT LAN Manager (NTLM) authentication or better. The authenticated user name is then compared to a list of users and groups permitted to access the node and access is granted or denied based on that list.
• Assembly Loading: Service assembly loading can be restricted only to load authenticode-signed assemblies whose signature was created by a certificate routed in the local user or machine's trusted certification list.
• Network Access: A node can be configured, using standard Common Language Runtime tools, to restrict the .NET Code Access Security (CAS) permissions available to a service or set of services. The DSS runtime contains a CAS permission that controls access to network resources. If a service does not have this permission then it can only access services within the same node.

In addition, RDS 4 adds to the security model to make sure that DSS nodes are secure by default as far as network connections are concerned. DSS nodes do not listen on all interfaces, but only on the loopback address (localhost or 127.0.0.1).

This topic explains in more detail how these mechanisms work. Topic DSS Node Security Configuration explains how to configure the security settings for a DSS node and topic DSS Node Security Runtime Interaction how to interact with the security manager at runtime.

Allow Unsecured Remote Access

As of RDS 4, the security model is designed to be secure by default. DSS nodes no longer listen on all network interfaces, but only on the loopback address (localhost or 127.0.0.1).

If you want DSS Nodes on different computers to communicate with each other, or you want to use a web browser from another computer to access a DSS node, then you must enable network access. To obtain the old DSS behavior, you must adjust the DssHost.exe.config (or DssHost32.exe.config) so that AllowUnsecuredRemoteAccess is set to true. (Search the file. The key is already present but set to false. See DSS Application Configuration File.) The name of this parameter reflects the fact that connections between nodes are not encrypted, so they are by definition unsecure due to the risk of eavesdropping. Connection requests, however, are always Authenticated. (See the section below on Authentication).

Note that this change also applies to VPL which has its own configuration files VplHost.exe.config and VplHost32.exe.config.

If you have used previous versions of RDS on your computer, or there are multiple users, you might need to adjust the HTTP Reservations (also called URL Access Control Lists, or urlacls). See the details of the HttpReserve Tool.

The HttpReserve tool allows you to specify user accounts that are allowed to listen on particular URLs. (If you are an Administrator and you start a DSS Commmand Prompt as an Administrator, then you do not need to use HttpReserve).

To see which URLs are currently reserved, you can use the netsh utility. You must be running as an Administrator to use HttpReserve or netsh. Open a DSS Command Prompt window by right-clicking on it in the Start Menu and selecting Run as Administrator. When the window appears, enter the command:

netsh http show urlacl

This will list all of the current Access Control Lists (ACLs). The old type of ACL is similar to http://+:50000/. With the change to restricted access, ACLs now look like http://127.0.0.1:50000/.

More information about the netsh command is available from the Technet page Netsh Commands for Hypertext Transfer Protocol. More information about URL ACLs and their order of priority is available from Routing Incoming Requests.

If there is no URL ACL defined for the current user, or it is incorrectly defined, then DSS will be unable to start. The error message lists one of the possible causes as not having permissions to listen for HTTP requests.

If you start a DSS Command Prompt as an Administrator, then DSS will start even without a reservation. However, you will find that you cannot access the DSS node using a web browser, even if you are on the same computer. You will receive an error message:
HTTP Error 503. The service is unavailable.

If you enable remote access, then you also have to change the HTTP Reservations. A new qualifier, Prefix, has been added to the HttpReserve tool to handle the extra parameter, e.g. + or 127.0.0.1. For instance, you might need to issue the following commands:

HttpReserve /Remove /Prefix:127.0.0.1 /Port:50000 /User:<username> /Domain:<domain>
HttpReserve /Prefix:+ /Port:50000 /User:<username> /Domain:<domain>

Fill in the appropriate username and domain. If your computer is not joined to a domain, then use the name of the computer instead of a domain name.

If you decide to revert back to the secure configuration, you need to issue these HttpReserve commands again but with the Prefixes swapped.

You can also use the netsh command instead of HttpReserve. The relevant commands are:

netsh http delete urlacl
netsh http add urlacl

If you enter one of these commands at the command prompt, you will see some abbreviated help text. These commands are not explained in this Help file.

Authentication

When accepting an incoming transport connection the DSS node establishes the identity of the remote party using NTLM or better. When authentication is enabled this occurs regardless of whether the connection is from another DSS Node using Decentralized Software Services Protocol over TCP or HTTP, or from a Web browser using HTTP.

Internet Explorer (IE) does NTLM authentication automatically for you in the background. Other web browsers might not do this, and as a result you might see a Login Dialog pop up on the screen. You must enter the username and password of the account that was used to start the DSS node. If your computer is not in a domain, use the computer name instead. If you do not have a password on the account that you logged in to, you might find that it is impossible to connect. For more information, see DSS Node Security Configuration.

Internally the DSS node then can associate an impersonation token for the remote user with the connection (the impersonation level used by the DSS node is Identify). The impersonation token contains the remote user's Security Identifier (SID) and a list of the groups that the remote user is a member of, expressed as a list of SIDs.

To determine whether the remote user has permission to access the current node the following checks are made:

1. If the remote user is the same as the user context in which the node is running. The current user always has all rights on the node. This prevents a scenario where a node is running with nobody having permission to access it.
2. If the remote user's SID or any of their group SIDs are in the list of UserPermissions, the user is given the union of all rights associated with the matching entries.
3. If the user has the rights All, allow the connection, otherwise refuse the incoming connection.

The list of UserPermissions is purely an allow list. There is no mechanism to specifically deny access to a user or group of users.

Service Assembly Loading

Before a service instance can be created, the assembly in which it is implemented is loaded by the DSS runtime. If the DSS node has been configured only to load Authenticode service assemblies then the assembly evidence is examined to determine if the assembly has been Authenticode signed before the service instance is initialized. In this case only assemblies signed by certificates that are issued by trusted issuers, as established by the local user and machine certificate stores, will be loaded.

Network Access Permission

There are three ways in which a service may establish communications with another service:

• Declaring a service partner using the partner attribute at service design time.
• Using a DSS manifest at service startup time.
• Using a forwarder created with DsspServiceBase.ServiceForwarder<T>() or DsspServiceBase.ServiceForwarderUnknownType() at service runtime.

If the third of these options is used, the service requires the DssNetworkPermission CAS permission to create a forwarder to a service on another node. This can be either on the same machine or on another machine. If a service is loaded as FullTrust it implicitly has this permission.

A DSS service can be restricted from accessing the network by creating a CAS policy that restricts the permissions  the service in question can use. If the assembly containing the service does not have the DssNetworkPermission, then the service will not be able to create a forwarder to a remote service.

If a service is restricted to only have the execution permission, the only capabilities that the service has are those that it can access through the interfaces made available in the DsspServiceBase class. This allows a service to interact with other services, but it cannot send data to the network without the DssNetworkPermission class.

DSS User Guide: DSS Security Configuration File

Windows Security: Security Identifiers | Authenticode Signing a DLL

.NET Framework Developer's Guide: Code Access Security | Code Access Security Policy Tool (Caspol.exe) | .NET Framework Configuration Tool (Mscorcfg.msc)

© 2012 Microsoft Corporation. All Rights Reserved.