In most aspects, a Windows service is an application like any other. You can use code access security to specify the permissions that this application needs and control whether those permissions are available by using the .NET Framework configuration tool.
But because Windows services are launched at bootup time, and run for the entire time that the operating system is loaded, you need to pay special attention to the security context in which they run. The security context for a service is initially specified by the Account property of the ServiceProcessInstaller object that was used to place the service on the system (although the user can later change this context by using the Services administrative tool). .NET lets you choose one of the four values of the ServiceAccount enumeration for this property:
The LocalService account is a built-in account that has few privileges on the local computer. When accessing resources from a remote computer, the LocalService account presents anonymous credentials.
The NetworkService account is a built-in account that has few privileges on the local computer. When accessing resources from a remote computer, the NetworkService account presents the computer's credentials.
The LocalSystem account is a built-in account that has high privileges on the local computer. When accessing resources from a remote computer, the LocalSystem account presents the computer's credentials.
Some Accounts Are XP-Only The LocalService and NetworkService accounts are only available on Windows XP and Windows .NET Server. These accounts do not exist on Windows 2000 or older operating systems.
When you select the User value for the Account property, you must also supply a valid Windows username and password. The service runs with the privileges of the specified user and presents that user's credentials when requesting network resources.
The LocalSystem account is used for most of the built-in services in Windows, such as the Computer Browser, Event Log, and Indexing services. These are services that require extensive access to resources on your computer to do their work. It might be tempting to install your own services using this account as well, but you should consider carefully whether your services need such sweeping privileges. Remember that ease of use is balanced by danger in this case. If you've made an error in your code, an attacker could potentially exploit your service to gain the privileges of the account under which it runs. If that account is the LocalSystem account, a successful attacker could take over the entire computer.