Secure application development: Least Privilege, User Account Control and ClickOnce

Unrestricted access is dangerous!

Performing development work with the fewest rights on a Windows platform is important from two different, but interrelated, perspectives.

Firstly, as a developer you need to reduce the risks of both system downtime and loss of data within your development environment. Infection by a virus could cause both of these.

Secondly, developing with least privilege contributes to the production of applications that users can work with securely.

Up until now, the solution to this has been to focus on the file permissions and user rights granted to the Windows account that the application will run under. Windows Vista extends this, with the new User Account Control feature. Also ClickOnce, a new development paradigm introduced with Visual Studio 2005, will introduce Code Access Security into the equation.

But I can get more done without security restrictions!

Many PC users work using an account which is part of the administrators group. Even though the computing industry, and particularly Microsoft, has endeavoured to persuade users otherwise, this practice is still quite common.

We all try to work faster and more productively. If a user needs to install software, for example, using a highly privileged account means that the user will have the necessary rights to perform that action. Thus, there is no interruption to work being done. Taking this to the extreme, running applications using an administrator-level account means that no security barriers will be put up whatever the user attempts to do on the system.

However, what happens when a highly privileged user accesses malicious software? In the nineties, it was common for email users to send each other executable files containing games or animations. If one of these files contained malicious code, it would run with the user’s administrative privileges, and have access to the Windows operating system folder, Program Files, sensitive registry settings – in fact, everything.

Since then, the number of vectors for transferring viruses, worms, and other types of malicious code has increased rapidly – for instance, macro viruses are transferred through popular productivity tools such as Word.

So, even though working with unrestricted access makes certain tasks easier, the potential dangers from malicious code are made much, much greater.

1

So what type of user account should be used when I develop software?

To avoid some of the issues defined above, I recommend using two accounts: A least privilege account which I log on with to perform most of my development

work. This is placed in the Users group. A highly privileged account, placed in the Administrators group

The Users group has most of the user rights I need to work with my computer productively, including:

Access this computer from the network Log on locally Remove computer from docking station Shut down the system

Obviously, this may vary with the version of Windows in use. However, working with Office, browsing with Internet Explorer and Windows Explorer, and accessing email can all take place unhindered.

There are four scenarios where higher privileges are required: Performing admin tasks, such as System Restore or creating local users and

groups Installing applications – you need access to the Windows and Program Files

folders, as well as certain sensitive registry keys Running applications which require excessive privileges – these have usually

been developed using an admin account and were never tested to see if they could run with least privilege

Developing and debugging applications with older versions of Visual Studio

How do I perform activities that require higher privileges?

This is where the Secondary Logon Service saves a lot of time and effort. This service (introduced with Windows 2000) allows the running of selected applications under a different user account, and is utilised via the ‘Run As…’ option.

Below is an example where I have chosen to run the System Restore wizard under a different account. Right clicking the menu item brings up the ‘Run As..’ option:

2

The user is then presented with a dialog box, allowing them to choose an account and enter the password for that account. In this example, I’ve chosen my highly privileged ‘ChrisAdmin’ account:

As a result, up pops the System Restore wizard, and I can use it with Administrator privileges.

It’s often useful to have an administrative shell for browsing and accessing functionality. For instance, an admin-level Explorer interface would allow one to alter certain protected files when necessary (such as adding a record to the hosts file). It’s not possible to use Windows Explorer in this way – it uses a single process, so you won’t be able to open another instance under a different user account. However, it’s possible to open another instance of Internet Explorer, and then type a file path into the Address bar. Here’s Internet Explorer on my system, opened using the ‘Run As…’ option.

3

You will have noticed that the IE toolbars are bright red. This is achieved by adding the file path of a small red bitmap to the HKEY_CURRENT_USER/Software/Microsoft/Internet Explorer/Toolbar/BackBitmap registry value. The entry doesn’t exist until you create it. Why do this? Well, you may notice that if you click on a hyperlink when you already have an instance of IE open, the link will open in that instance. If you don’t make your admin-level IE distinctive, you may open a link in that instance without noticing it’s running with admin privileges. This would potentially leave your system open to the downloading of malicious code.

Typing C:\ into the Address Bar allows me to browse the file system on the C drive as an admin. I can also type in ‘Control Panel’, and see the list of system tools. By navigating from there down to ‘Administrative Tools’ I can access the most commonly used configuration applets.

By double clicking on the Computer Management icon (or any other item in this explorer pane) I open an instance that runs with the same credentials i.e. as an admin level user. I can then use any aspects of this tool, such as administering users and groups.

4

What about running Visual Studio?

The various versions of Visual Studio had different requirements in this respect.

Some complexity was involved with debugging when using Visual Studio 1.x – here is an article explaining how to set up debugging:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/tchDevelopingSoftwareInVisualStudioNETWithNon-AdministrativePrivileges.asp

Note that the Debugger Users group was created during install on .Net 1.x so that the Machine Debug Manager (MDM) could check if the privilege had been granted. This group simply provided an access control check for the MDM - it didn’t actually set up any rights to the operating system.

Visual Studio 2005 has dispensed with the need for a number of VS specific groups, such as the Debugger Users. This means that you can debug Windows applications as a member of the Users group with VS 2005. No extra privileges or configurations are required.

For ASP.Net 2.0 applications, you’re debugging an application running in a different context, which does still require extra privileges. You have two solutions:

Set up the necessary privileges for debugging using your low privilege user account

o Create a new Application Pool. Set the Identity of this Application Pool to your low privilege account

o Add your low privilege account to the IIS_WPG group o Add the ASP.NET Project to this Application Pool

Run the web application from a folder on the file system, rather than through Internet Information Services (IIS), using the ASP.Net Development Server. The ASP.Net Development Server (formerly called Cassini) allows a developer to run the application using his/her own credentials, without having to worry about many of the configuration issues associated with IIS.

Advantages of debugging with Visual Studio 2005

The latest version of Visual Studio makes it a great deal easier to develop with least privilege.

Debugging a Windows application as an ordinary user reduces the occurrence of security bugs – you will know exactly how the application will run on an ordinary non-development PC. You also lessen the risks to your own development server that would arise from working with excessive privilege.

5

For ASP.Net web sites it is essential to re-test any application with the type of account that it will be running under. It’s unlikely that a member of the Users group will be accessing across the internet (browser users in another country would probably not need the ‘Remove computer from docking station’ right on your web server!).

However, what about applications that may need to run under a different context? You may need to write an application that accesses and manipulates objects within Active Directory. This would require greater rights than are offered by the Users group, which may be appropriate if the tool is for use by Administrators.

Solution: Windows Virtual Server 2005 R2

A versatile option would be to use Windows Virtual Server 2005 R2. I currently have this set up with a Microsoft Windows operating system, Visual Studio 2005 and SQL Server 2005 Dev Edition. This means that I can run using higher privileges, without affecting my host system. I can even change the time on the system clock, which you would still have to log off and on to achieve if running as a least privilege user.

It’s important to make sure that you don’t connect the Virtual PC to a corporate network via the Network Adaptor unless the VPC is protected by anti-virus software. This is because a virtual PC, if connected to the network, could affect other computers if it is infected with a worm or virus. As a file server (or any other type of member server) is concerned, there’s no difference between a normal PC and a Virtual one. Don’t use the VPC to browse the internet or run non-certified software when logged on as an administrator as this could introduce malicious code to your VPC.

I keep base copy of the VPC file where no development has taken place. After developing an application, I test it on a fresh instance of the base VPC to make sure that it still runs without any security bugs.

Future Directions with Microsoft Windows Vista

To encourage users to work using non-admin accounts, Microsoft have introduced the concept of ‘right privilege at the right time’ for Vista, the next version of Windows. This new facility is called User Account Control.

One logs on using an account belonging to the ‘Users’ group. If it’s necessary to access any resources requiring higher privileges, then the opportunity to enter admin credentials is offered. Lets look at the (until now) awkward issue of altering the time on the system clock.

The dialog for altering the time has a button, marked with the Windows security ‘shield’ icon, labelled ‘Change Date and Time’.

6

Clicking on this button displays a dialog requiring the entry of admin level credentials.

Entering these credentials allows the user to alter the system time.

Notice the wording at the bottom of the prompt – ‘If you do not trust the source do not use this program. This program can potentially harm your computer’. But that’s you, the

7

person logged in, surely? Not quite. This may be an instance of the category of software we mentioned earlier, which requires excessive privileges in order to run.

Under Microsoft Windows Vista, if this type of software tries to access a sensitive system resource, even when running under an admin level account, then the user can still decide whether this is allowed.

It’s possible to configure Windows Vista so that even an admin has to agree to the use of higher privileges. It works like this:

User logs on with highly privileged account User tries to access a resource that requires admin level rights Prompt is shown asking whether user wishes to use admin level rights If user allows this, then the resource is accessed

This makes admin users aware of when they are using higher level rights.

Finally, on the subject of software that can’t run under an ordinary user account, a new feature of Windows Vista called virtualization allows those resources to run without damaging system files and registry keys. As an application attempts to write to a file in the Program Files directory (for example), a virtual copy of that file is created within the user’s profile. This ‘virtualized’ file is then available for the application to interact with. A similar operation takes place when accessing certain parts of the registry. The original file or key remains unaltered.

Here are the settings available for User Account Control within Vista’s Local Security Settings applet:

It should be noted that the screen grabs of Windows Vista in this article are from a beta version. The functionality available in the final version may change.

Here is a guide to developing applications for beta 1:

http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp

8

Build 5308 increased the number of permissions granted to a least privilege user, including:

View system clock and calendar Change time zone Install Wired Equivalent Privacy (WEP) to connect to secure wireless networks Change display settings Change power management settings Install fonts Add printers and other devices that have the required drivers installed on

computer or are provided by an IT administrator Create and configure a Virtual Private Network connection Download and install updates using User Account Control compatible installer

The guidelines for running with least privilege on Vista are still being finalised, and once this baseline has been completed developers will be able to produce applications that can run on Vista without disruption.

Smart Clients and Code Access Security

ClickOnce is a new development paradigm, introduced with .Net 2.0. These ‘Smart Clients’ combine the advantages of rich (Windows Forms) clients:

rich user experience developer productivity responsive user interface offline access

and thin (web) clients: broad reach easy change management ease of deployment minimal system impact install and run per user

To install a ClickOnce application, you simply navigate to the web page where the application has been published:

9

Click once (so that’s where the name came from!) and your application is installed and ready to go. Rather than installing to Program Files (remember, a least privilege user doesn’t have access to this folder), the application is installed to the part of the file system containing the user’s profile:

ClickOnce implements Code Access Security in a more intuitive way than previous versions for ordinary users.

The application is hosted by a process called AppLaunch.exe. When you install from the publishing web site, AppLaunch.exe checks to see if the application is in the list of Trusted Applications. If so, the application downloads and runs.

If not, the TrustManager component takes over. First, it checks to see if the executable has been signed by a Trusted Publisher (the signing certificate must be in this folder in the certificate store). If so, the software downloads and runs.

10

If not, the permissions required in the application manifest are compared to the permissions allowed by the Zone of the URL. If the permissions are compatible, the application downloads and runs.

If not, a security dialog is shown to the user.

The user can then decide whether or not to install the application. If the choice is made to install, then the app is added to the list of Trusted Applications. Whenever it runs, it is allowed all of the permissions listed in its manifest.

What does this mean from a developer’s point of view? How will you be able to reliably create applications that run on the desktop?

On the properties of the ClickOnce project is a dialog containing the new permissions calculator. This calculates the permissions required for running the application, according to the zone it will be installed from.

11

Clicking on the Advanced button brings up the option to debug the application with the selected permission set.

This means that your code, while debugging, will throw a security exception if it demands rights that are not granted by the zone you have chosen.

Summary

Windows Vista will be Microsoft’s most secure operating system to date. Two of the new features, User Account Control and Virtualization, make it even easier to work productively using a least privilege account.

ClickOnce applications represent a challenge for developers when creating software. Visual Studio 2005 provides tools to assist you in creating applications that can run on the user’s desktop without losing productivity.

It is possible to work productively without logging on as an administrator. The inconvenience is not as great as some people may tell you.

If you can develop applications as a member of the Users group you will reduce risks and thus costs, and also ensure your organisation’s reputation. Testing to ensure this compatibility will mean that users of your applications can work with least privilege.

The nature of our networked world means that more threats than ever are ready to take advantage of an insecure computer. Upgrading to Visual Studio 2005 makes it easier to mitigate the effects of those threats, while at the same time working productively.

12