NxtGenUG - Article

Code Access Security and Click Once

Web and Windows applications both have their own advantages and disadvantages. So many organizations love the ease with which an aspx based app can be deployed and maintained. You don't have to install it on every client, so you avoid creating a huge maintenance issue for the system admin. Also, development and improvement of the application can take place more frequently, based on feedback from the users.

The downside is that you have a less rich user interface, lacking the interaction that some types of user prefer. A good example of this is telephone help desk staff - these users want hotkeys in order to move through screens quickly, and sometimes even prefer old DOS style screens.

However, rolling out this type of app across all client workstations can be a huge undertaking.

Up until now the choice was between rich client (Windows app) and thin client (web app). With the introduction of Visual Studio 2005, we now have another alternative - the smart client.

Smart clients are a new type of .Net application, embodying some of the best points of both rich and thin clients. From rich clients, they take features such as:
• rich user experience
• developer productivity
• responsive user interface
• offline access

From the thin client they have:
• broad reach
• easy change management
• ease of deployment
• minimal system impact
• install and run per user

To install a click once application, you simply navigate to the web page where the application has been published.

Click once (Ah! That’s where the name came from) and your application is installed and ready to go.

You’ll then find it on your programs menu, and it can be removed via the ‘Add/Remove Programs’ applet in the Control Panel.

When you run the application, if an update has been published to the web site, the app will prompt you to get the latest version.

The application is not installed to Program files, but to a per user area within the Documents and Settings folder.

All very easy, but how do we keep this sort of application secure? In particular, we need to answer the following questions:
• How is resource access controlled?
• How do we know that we can trust the producers of the application?
• Can the user decide to override the trust decisions?

Code Access Security (CAS) is one of the layers of security that is applied to ClickOnce applications. CAS is sometimes underused in many applications, possibly because some developers feel that it is a little too complex. In ClickOnce deployment, CAS has now become a more mature, easier to use technology.

Perhaps the hardest thing to understand with CAS is that you’re not making decisions based on user identity. It’s based on identity of the code. For instance, a policy can be written dictating that code signed with a particular strong name key might be granted access to read the contents of a file, whereas code coming from a certain URL is allowed access to certain registry keys. Absolute restrictions on what an application can do are useful in many ways – for instance, this can reduce the damage that an elevation of privilege attack is capable of.

This is taken a step further with ClickOnce. Code is assigned permissions according to which zone it is downloaded from:
• Local Computer
• Local Intranet
• Internet
• Trusted Sites
• Untrusted Sites

Have a look at the .Net 2.0 Framework Configuration tool, under runtime security policy. You’ll see all of the different zones. You can look at the permissions available for code downloaded from a specific zone.

If the code is downloaded from a server in the user’s local intranet, then these will be the permissions that the app will have. These permissions will be compared with the permissions required by the ClickOnce app before it is run. The app’s required permissions are kept in a manifest file:

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<applicationRequestMinimum>
<defaultAssemblyRequest permissionSetReference="Custom" />
<PermissionSet class="System.Security.PermissionSet" version="1" ID="Custom" SameSite="site">
<IPermission class… />
<IPermission class… />
<IPermission class… />
</PermissionSet>
</applicationRequestMinimum>
</security>
</trustInfo>
</asmv1:assembly>

This is the app – all it does is access the contents of a file on the user’s PC. However, controlling resource access such as this is precisely what CAS was designed for.

Another aspect of ClickOnce and CAS is the use of trusted publishers. Don’t use strong names to identify code – code signing certificates are the new baseline for ClickOnce. The client has to have the relevant certificates in the Windows certificate store:
• Certificate of CA that issued the publisher certificate – this must be placed in the Trusted Root Certification Authorities folder
• Publisher certificate – this must be in the Trusted Publishers folder

Two applications control the application of Code Access Security to the ClickOnce app. These are the AppLauncher and TrustManager.

The AppLauncher hosts all ClickOnce apps within a sandboxed AppDomain. If you look at the Task Manager, you can see AppLaunch.exe.

The TrustManager makes trust decisions regarding whether the application can be run. Firstly, AppLaunch.exe checks to see if this is a trusted application. These can be seen in the .Net Framework Configuration tool, under Runtime Security Policy/User/Trusted Applications.

If this is not a trusted application, the security decisions are handed over to the TrustManager. TrustManager checks to see whether the app has been signed by a trusted publisher.

A check is made to see if the code signing certificate is in the Trusted Publishers folder of the certificate store. The permissions in the applications manifest are also checked. Permissions for the zone that the app is downloaded from are compared.

If the application requires more permissions than are allowed for the zone, or if the publisher is not trusted, then the user is able to make the decision as to whether the application can download and run. A security warning screen is presented to the user, so that he/she can decide to overrule the security decisions made by the TrustManager.

Clicking on the link at the bottom brings up more details of the actual security warning.

If the user decides to install, then the application will be granted the necessary CAS permissions, and will run every time with these permissions in the sandboxed AppDomain provided by the AppLaunch.exe. The app would now be added to the list of trusted applications.

Elevation of permissions can be turned off by an administrator, so the sysadmin can still make sure that the default permissions for the different zones are adhered to.

I’ve heard a couple of developers say this warning dialog turns a ClickOnce application into ‘click twice’, and also ask how do we get rid of the annoying dialog? Look, deciding whether an application is allowed to run with greater privileges is a very important decision, and providing a clear, concise security warning to inform the user is absolutely necessary. Besides, most of are used to a lot more than two clicks to install any application.

What about the developer’s point of view – how do we produce something that will run on the user’s PC? There’s a permissions calculator in Visual Studio 2005 which checks the code to see if it falls within the permissions granted for different zones.

It’s quite a feat to make Code Access Security apply to smart clients. With AppLaunch.exe and the TrustManager, CAS also becomes easy to manage, and easy to produce applications for.

One of the really great things about ClickOnce and CAS is that it was originally designed for Vista. We’re starting to get a lot of these technologies earlier for Win 2003 and XP, which is marvelous.

I’m going to be giving a talk on using CAS with VS 2005 for the NextGenUG on May 22nd. We’ll be looking at ClickOnce projects, as well as covering some design patterns for securing web applications.