Programming4us
         
 
 
Programming

Security Privileges and Services

10/17/2010 6:05:06 PM
You have to think about a number of things when it comes to services and security. Services themselves have to run in a security context that has permissions to do what you program the service to do. Imagine that you are programing the service to read a file from the hard disk, read a setting from the registry, or even log on to a Windows Authentication–only SQL Server. If the account that your services runs under does not have the appropriate privileges, your service will fail to perform the tasks you assigned it, and although the service itself may actually run, it will be useless.

Running a service in a higher privileged context than is required can cause security holes, which provide opportunities for unapproved network access, application access, and data loss. Never grant more authority than your service requires to perform the tasks required of it.

You should always determine what your service needs to do before you begin to code it. Then, based on these needs, you determine the required security rights. To help determine what options you have in terms of security, let’s look at the default settings you have to choose from when building a service.

Service Account Security

When you build a service, you have to select an account that the service will run under. This is considered the security context, because the account (context) that your service runs under is not necessarily the same as the user who may be logged on at the time.

For example, if you open up the Services Control Panel and look at the Log On As column, you will see many different listings. Let’s look at what the choices are when we install a service.


Let’s open up the Services Control Panel and right-click the Tutorials service. Select Properties and then click the Log On tab.

Local System

You have two options: to run as a Local System Account or to run as a specific user account. For the moment ignore the option Allow Service To Interact With Desktop—I’ll cover that in a moment. Most services use some predefined system accounts that are created when the operating system is installed. Although these accounts are technically user accounts, they are predefined with specific security attributes, privileges, and default security response types when queried by remote computers. In most cases you should use one of the predefined NetworkService or LocalService accounts.

The Local System account itself has access to most resources on the local computer that it exists on. It has no password and is not considered a real user. It is an account created for use by the service control manager (SCM) under whose context many services run. However, this account has quite extensive privileges, and any service running under this account has those privileges. For this reason it is important to avoid using this account unless necessary. You can and should create an account with the minimum privileges required to perform the service’s duties.

Note one important thing about the Local System account: Although it has a large amount of privileges when running on the local computer, it has almost no privileges when attempting to access network resources. For this reason, the Local System requires null sessions—sessions with only anonymous authentication (in other words, no authentication).

You can restrict null sessions on computers throughout your network, protecting them from services running on remote computers. If you plan to access remote resources, it’s better in many situations to use the local computer’s Machine Account and then grant that account access to the remote resources.

User Accounts

You can create, define, and give any user account the required specific privileges and security rights—such as if you wanted the service to query data from a database on a computer running Microsoft SQL Server that requires a valid Windows account. You can set the service to run as a user who has Windows Authentication to Microsoft SQL Server—whether a local account or a domain account—and then when the service queries SQL Server, it will send the credentials as if it were that. Let’s look at the options:

  • User This option causes the system to prompt for a valid user name and password when the service is installed and runs in the context of an account specified by a single user on the network. This is the most powerful of all security contexts because you define what access the account has when the account is created. If you run the service as a domain enterprise administrator, the service will have the privileges of that domain administrator. You need to define the exact privileges that are required by a service to determine whether this is a viable and reasonable option. You’d be hard-pressed to find a situation that would require such extreme privileges. Under Windows 2000, Windows Server 2003, and Windows Vista, you are best off assigning your service as a Network Service account or a Machine account. After doing so, you can grant privileges to other computers, or services such as Microsoft MSMQ, by adding the machine account that the service runs under to the remote resource.

  • Local Service A service running as a Local Service runs in the context of a reduced-privilege user on the local computer and presents anonymous credentials to any remote server. This option is appropriate for situations that require very limited security and that do not require access to remote network resources. Because the service would only access remote resources using null sessions with anonymous access, it is not recommended that you use it for network resource access.

    Null sessions (anonymous logons) pass no user name and no password to the local or remote resource for authentication. If the remote system has blocked null sessions or anonymous logon, you won’t be able to access the required resource. In this case you should consider using the Network Service account.

  • Local System This option runs in the context of an account that provides extensive local privileges and presents the computer’s credentials to any remote server. This is a very powerful account to use and will allow you to perform almost any action. You must be careful when using Local System as your security context because allowing a service to run as Local System grants more privileges than most services require. Consider this option only when requiring privileges equivalent to those of an administrator. In most cases, you should consider the more restrictive options and then extend the default privileges of those accounts, instead of granting the service more privileges under a Local System. If the service does not require elevated or interactive privileges, consider using Local Service or Network Service accounts instead.

  • Network Service A service running as a Network Service runs in the context of a non-privileged user on the local computer and presents the computer’s credentials to any remote server. This account is much more powerful than Local Service, but is still much more secure than Local System, especially when it comes to remote computers who query this service. External services running in the context of the Everyone and Authenticated Users groups merely receive anonymous credentials that they would not be able to use to spoof the computer credentials given by Local System.

What is spoofing? When services run in a security context higher than is required, they run the risk of external users attempting to mimic, or spoof, the credentials of the service itself. In this case, a malicious user may intend to use executables, batch command files, or other executable processes by exploiting the capabilities of your services. Once these processes are running, they have the same privileges as your service and therefore can spoof the service credentials and force the service to perform tasks it was not intended to perform—against other services or resources it was not granted explicit access to.

You may not always be clear about what you initially need, and sometimes you may need to rely on trial and error. If you are unsure, talk with your network administrator and work out how to create a user account that can be managed by your administrator so that it can be limited to doing only what it needs to do. In instances in which a service may need to run on a large number of computers and does not require special privileges or network access, consider using the LocalService or NetworkService accounts. If the service requires a lot of network access or privileges, a secured domain account is often the best option.

When deciding on the service account you want to use, the level of of security should be paramount. The choices can be considered in the following order, from most to least secure:

  • Local Service account

  • Network Service account

  • A local user account

  • A domain user account

  • Local System account

  • The local administrator account (not recommended)

  • A domain administrator account (not recommended)

Securing the Service

It is very important to think about not just what your service will do, or what security context it needs to run in, but how to protect your service and your business from unauthorized usage of your service and its functionality.

Imagine that you have a service that can download important customer information or internal employee information, sales figures, or other confidential information. In these cases you probably want to keep access to this service and its functionality secure. You want to limit the access that the service has.

Protecting Data

Let’s say you design a service that has the ability to download all customer and credit card information from one data store and then process the data to store into another data store. What do you need to secure?

  • Access to the data store that holds the customer information

  • Access to the directory to which the service downloads the information before processing

  • Access to the secondary data store that will hold the customer information

  • Access to temporary data and data connections

Each type of access has particular issues that must be addressed. However, as with all applications or services, each type of access has different types of functionality. Therefore you should always look at your service and determine what actions it takes, how you will perform them, and which of those actions need to be secured. That last step—determining how to secure them—is important. Local development resources at your company, on the Internet, and from local administrators can often help you with any of these steps.

Access to the Data Store That Holds the Customer Information

Normally this type of data is stored in a back-end database. Database servers that run on the Windows platform usually support NTLM and Kerberos-type authentication, as well as SQL Server authentication, using built-in logons. In this situation we have to figure out how to allow the service access to the data without providing too much access or access that can be abused by someone with malicious intent.

As I’ll explain in the following sections, you can have the service run in the context of a user who has access to the database, or you can supply the service with the security context or logon information with which it can impersonate the user’s security access. You can also specify security logon information in the connection string used to connect to the database.

As a User

If you decide to run the service as a user with security rights, make sure that the user account has only the privileges required to retrieve the data and to process it locally, especially if you plan to store the data temporarily on the local disk.

Impersonation

If you decide to supply the service with the security credentials for either a Windows account or a SQL Server logon, you have to decide how to get this information to the service while keeping it safe. It does no good to secure the use of your service if you make it easy to obtain the logon credentials that provide access to the confidential information.

You can place the user name and password in an encrypted file or encrypted registry key, or you can use a secondary Web Service or COM+ application that has permission to access the database on behalf of the service. Both are good ways to provide access to the data while securing logon information.

Access to the Directory to Which the Service Downloads the Information Before Processing

It is possible to process the data in two formats. The first format is memory only, where you might query the information and then store it in local memory resident ADO.NET datasets, or other memory-mapped data objects that are then processed directly to the secondary data store. The second option is to save the data temporarily to the file system, where it is either processed by the same service—possibly on a separate thread—or by another service.

Although not a direct concern for the developer, from an operational support and security point of view, if the data is stored in memory, your operations team should keep track of access to the server where the data is being processed. Depending on the data itself, you might not be able to encrypt the memory used to store the data while it is being processed. This means you must be diligent about local server access.

When determining whether you should store data in temporary local files, you should look at some possible solutions for helping to ensure the safety of your data:

  • Encrypt the data as it is saved to disk.

  • Store temporary files in encrypted folders accessible only by the service account.

  • Process the file in memory and not create an unencrypted version on disk.

Access to the Secondary Data Store That Will Hold the Customer Information

At times you will be pulling data from one database or data store and you might want to migrate it, or convert it to another format and then store it in a secondary database or data store. In this case you will need to review the security model and approach that you use.

Imagine that you are running the service as a local user account or even as a domain account or machine account. The service itself might have access to the data store that you retrieve from, but not have access to the back end. This could be due to trust issues in the domain, multi-homed servers, or any other security or configuration requirement on your network or business. If this is the case, your service could be sharing the data between two components, instantiated by the service but running under two different security contexts. In this case the service is running under one account and so is child process 1 (or thread 1) and the second thread needs to run as a secondary account. In this case you are passing data through the service itself between two threads or two components created by the service, but running under different security contexts. This following list, while not exhaustive, gives you some options for possible solutions to this problem:

  • Create matching SQL logons on both servers and then share this data between both connections.

  • Use Windows authentication by running the service under an account that has access to both data stores. Use a SQL logon for one data store and use the security context of the service for the other.

  • Use multiple user security contexts on a per-thread basis and share the data between the threads. This option requires that you inherent from existing security contexts, create new secuirty contexts that you then pass onto a new thread, or that you have the thread impersonate a security context that has the required access. Although there aren’t many situations in which you would run a service in such a model, threading and services are not limited to a single security context. Microsoft provides APIs and .NET methods for creating such threads.

  • Use COM+ services or Web Services to perform the data retrieval and storage.

You can perform data retrieval from different data sources in many different ways. What’s important is to make sure that you don’t give the service too much authorization, while at the same time protecting the logon information so that data on both servers is protected.

Access to the Temporary Data and Data Connections

Not only do you need to make sure the data is protected while you are processing it, but you also need to make sure that the data is secured once it has been processed. Make sure that you clear any data and memory buffers, close any unused connections and recordsets, and most important, make sure to destroy any locally stored data.

Other -----------------
- Client Credentials
- User-Level Security : Service Credentials
- User-Level Security : Custom Authentication
- User-Level Security : Authorization and Impersonation (part 4) - Impersonation
- User-Level Security : Authorization and Impersonation (part 3) - Security Token Authentication
- User-Level Security : Authorization and Impersonation (part 2) - Claims-Based Authorization
- User-Level Security : Authorization and Impersonation (part 1) - Authorization
- Publisher Certificates
- Using LINQ To SQL
- Service Management API (part 2) - Making API Requests
- Service Management API (part 1)
- Windows Services : A Service Control Shell
- ASP.NET Applications and the Web Server
- Internet Information Services (IIS)
- Managing Websites with IIS Manager (part 7) - Confidentiality with SSL and Certificates
- Managing Websites with IIS Manager (part 6) - The Machine Key and Windows Authentication
- Managing Websites with IIS Manager (part 5) - The Default Page and Custom Error Pages
- Managing Websites with IIS Manager (part 4) - Configuration
- Managing Websites with IIS Manager (part 3) - The ASP.NET Account
- Managing Websites with IIS Manager (part 2) - Understanding Application Pools
 
 
Most View
- Performing SharePoint 2010 Installations (part 3)
- Exchange Server 2010 Mailbox Services Configuration (part 1)
- Exchange Server 2010 : Managing Details Templates
- Windows Phone 7 : Fixing Mistakes
- Setting Up a Full-Text Index (part 2) - Full-Text Indexing of BLOBs and XML
- Exchange Server 2010 : Designing and Implementing AD RMS Integration (part 3) - Transport and Journal Report Decryption
- Managing SQL Server Permissions (part 4) - Using T-SQL to Manage Permissions
- Active Directory Domain Services 2008: Disable the Directory Service Replication Auditing Subcategory
- Sharepoint 2010 : Creating a .NET Connector in Visual Studio 2010 (part 2) - BDC Modeling Tools & Defining the BDC Model
- Microsoft Systems Management Server 2003 : Rolling Back and Uninstalling a Scripted Installation
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS