.NET Security Blog : ClickOnce

CLR v4 Security Policy Roundup

shawnfa — Fri, 12 Jun 2009 21:33:00 GMT

Over the last few weeks we’ve been taking a look at the updates to the CLR security policy system in the v4 release of the .NET Framework. Here’s a quick index of those topics:

Overview

Updating code to work with the new model

Implicit uses of CAS policy part 1 (Assembly.Load with Evidence, AppDomain creation with Evidence)
Implicit uses of CAS policy part 2 (loading assemblies from remote sources)
Explicit uses of CAS policy (APIs such as SecurityManager which directly use CAS policy)

Temporarily re-enabling CAS policy during migration

The NetFx40_LegacySecurityPolicy config file switch

FullTrust on the LocalIntranet

shawnfa — Mon, 12 May 2008 20:49:36 GMT

We released the first beta of .NET 3.5 SP 1 this morning, and it includes a change to the default grant set for applications launched from the LocalIntranet zone. The quick summary is that as of .NET 3.5 SP1, applications run from a network share will receive a grant set of FullTrust by default, making them act the same as if they were launched off of your computer directly. Since this is an issue that I know a lot of people run into, I hope that this change makes it easier to use and deploy managed applications. For people who want to keep their machines working the same as they did for previous .NET Framework releases, you can set the DWORD registry value LegacyMyComputerZone to 1 in the HKLM\Software\Microsoft\.NETFramework registry key.

With the high-level summary out of the way, let's take a look under the hood to see what changed to make this possible :-)

The core of this change is a modification in how we assign evidence to network launched applications. When we see an .exe launched directly off a network share, rather than giving that .exe Zone evidence of LocalInranet, we instead give the .exe Zone evidence of MyComputer. This causes the .exe to match the default MyComputer code group rather than the LocalIntranet group, and in default CAS policy that code group grants FullTrust. (This also explains why the opt-out registry value is named LegacyMyComputerZone)

In addition to the entry point .exe of the application, we'll also extend this MyComputer evidence to any assembly loaded from the same directory as the .exe. So, if you place any managed .dll's immediately next to your .exe, those will also all be given FullTrust by default in .NET 3.5 SP1.

Since we're only including assemblies loaded from the same directory as the entry point application, things will just work for most applications, however more complicated programs that need to load assemblies from different subdirectories or other network shares may not see all of their assemblies get fully trusted by default. For these more types of applications, ClickOnce deployment is the recommended way to elevate to FullTrust.

We've specifically disabled this change for any hosted applications. So this means that if your program uses the CorBindToRuntime API to host the CLR, we won't start trusting assemblies it loads from a share. Similarly, hosts like Internet Explorer will not start trusting controls that it loads into the browser.

To summarize the under the hood changes, assemblies which will now receive Zone evidence of MyComputer and therefore be fully trusted by default are:

Any managed .exe which is launched directly from a network share
Any assembly in that .exe's process which is loaded from the same directory as the .exe itself was.

Assemblies which will not see this change include:

Assemblies loaded from a subdirectory of the share where the .exe was launched from
Assemblies loaded from shares other than the one where the main .exe was launched
Any assembly loaded on a machine with the LegacyMyComputer registry value set to 1
Any assembly loaded into a CLR host, including assemblies loaded into Internet Explorer as controls.
Any assembly loaded from shares by an application that was launched from the "real" MyComputer zone.

Avoiding Assembly Level Declarative Security

shawnfa — Tue, 02 Oct 2007 19:24:36 GMT

I've written in the past about the three assembly level declarative security actions: RequestMinimum, RequestOptional, and RequestRefuse. Although the CLR has supported these since v1.0, I tend to stay away from using them as much as I possibly can, and also recommend that others avoid them as well. Let me go through each one individually:

RequestMinimum

RequestMinimum is the most common of the three, and in fact is mentioned by a FxCop rule and automatically inserted by the C# compiler in some cases. There are several reasons I don't like to use this security action.

The first problem I have with RequestMinimum is a usability problem stemming from the fact that if your assembly is not granted its RequestMinimum permission set, the CLR will refuse to load it by throwing an exception. If the assembly in question happens to be the entry point of my application, that means the user of my app ends up staring down an unhandled exception dialog (since my code never got loaded, and therefore never had a chance to handle this error more gracefully). If my mother runs an app I give her and it throws a FileLoadException due to insufficient permissions, she's not going to have any idea what to do with that.

Even if the assembly is not the entry point assembly, gracefully handling failure to load due to RequestMinimum means that an application needs a try ... catch around every code path which could potentially lead to loading the assembly in question; that's not something that a lot of applications are setup to do.

The other problem I find with RequestMinimum is that in the case of writing a shared library it's very difficult to figure out what the correct grant set to request is. Unless all of the APIs being exposed require the same set of permissions, having only a single RequestMinimum set doesn't help much. For instance, an assembly like System.dll exposes hundreds of classes each with indivdual permission requirements varying from SecurityPermission/Execution to FullTrust. If we decided to use the minimum grant set of any API in the assembly as the ReuqestMinimum, we've somewhat defeated the purpose of the security action; now I cannot be assured that the assembly loading means that it has the required permissions to work in all cases. On the other hand, if I use the maximum grant set required, the assembly won't load even if an application was only intending to use APIs that would work in the grant set that the assembly is loaded into.

Finally, since security demands go against the entire call stack, even if the assembly in question has all the permissions that it needs to run doesn't mean that all assemblies and AppDomains on the call stack will have those permissions. So even if an assembly does have its minimum grant set met, it doesn't have any guarantee that its APIs will all work without throwing a SecurityException.

RequestOptional

RequestOptional is probably the least commonly used assembly level security action, and with good reason. This security action is somewhat poorly named, and people who use it for the first time often don't realize that it will actually remove permissions from your grant set. In fact, I run across RequestOptional most commonly when helping someone debug a SecurityException that they can't figure out. ("Why does this exception occur? All assemblies should be fully trusted!")

Even once you do understand the full effect of RequestOptional, the fact that it is confusingly named and that most people do not understand it is argument enough for me to stay away. Code readability is extremely important, and if I can expect that the next person to read through my code will be confused by that RequestOptional I stuck on my assembly, that's not a good thing -- especially when it comes to security.

RequestRefuse

I expect this is the most controversial security action to take a stance against. A good number of people probably use RequestRefuse as a least-privilege mechanism. My problem with that is that you're stating "I don't want permissions A and B", however when someone comes along and introduces permission C you haven't refused it, and therefore you still get it. Personally, I believe the CLR has other, much better, least-privilege mechanisms available -- and I prefer to use those whenever possible. (Sounds like the topic of a future blog post :-) ).

Finally, and this should come as no surprise to any regular visitors, I'm a huge fan of the model where every sandboxed AppDomain has exactly two permission sets -- FullTrust and one sandbox grant set. RequestRefuse (and RequestOptional) both detract from this model by creating multiple permission sets within an otherwise homogenous AppDomain. By keeping AppDomains entirely homogenous, it's much easier to reason about security within the domain. And, in my opinion, keeping the security model as simple as possible can only be goodness -- complexity can lead to mistakes in reasoning, which leads to security holes.

So What Instead?

Some of the abilities promised by the assembly level declarative security actions seem to be very useful at first glance. Notably the ability to specify a grant set that the code was tested to run in (which is what RequestMinimum seems to promise) and the ability to run with least privilege (via RequestRefuse).

For RequestMinimum, I think that ClickOnce is a far superior alternative for a variety of reasons. Most importantly, ClickOnce gives the user of the application a nicer experience when the application does not by default meet the minimum grant set. Rather than throwing an exception in the face of a non-developer, a friendly user interface is displayed which may even offer the ability to grant the application the ability to run.

Also, the grant set specified for a ClickOnce application applies to all of the assemblies in the application as well as the AppDomain (hey -- it's my favorite homogenous model again!). This means that you don't have to worry about the scenario where your assembly meets its minimum grant set, but some APIs still fail with SecurityExceptions because another assembly further up the call stack did not meet the minimum grant set.

That covers RequestMinimum -- but what about the least privilege promise of RequestRefuse? As AB might say -- that's another show.

Specifying Permissions for IE Controls in Orcas

shawnfa — Wed, 07 Mar 2007 22:25:00 GMT

One of my most read blog posts (and one of the reasons I created this blog in the first place -- to answer what was one of the most asked questions on the old .NET Security newsgroup), is my post about granting managed controls hosted in IE extra permissions. If you need to have a managed control run above its default grant set, the process getting this working in .NET versions through .NET 2.0 was relatively painful.

You needed to create an extra code group that granted your control the permissions required, and then get that policy deployed to all client machines. One of the more common ways of doing this is to use the .NET MMC snap-in to create a policy MSI file. However, those policy files are snapshots of policy and overwrite any other custom policy settings on each client machine. This means if a user has two controls they use that require an MSI prerequisite, they end up fighting for control over policy -- only the last one installed wins. There's also no guarantee that client machines have run my MSI file, so unless the control does runtime permission checking it will sometimes fail on misconfigured machines.

Versioning provides another challenge here. Since every CLR has independent security policy and IE will always load the latest runtime version when hosting a control, as soon as a new version of the CLR ships all changes in policy will no longer apply to hosted controls, and new MSIs will need to be created.

On top of all of these challenges, is the problem mentioned in the original blog post -- namely that the AppDomain hosting the control will only have Url and Zone evidence. If your code group uses a stronger membership condition (and it probably should) such as StrongName or Publisher, any demands will fail when they hit the AppDomain boundary because the domain will not match your code group and will have lower trust than your assembly. This required adding an assert at each of the control's entry points, which is not really a great coding practice.

With all of these problems, it's pretty obvious that we need a better solution for controls which need to run with higher permission than default. A lot of these problems apply to applications as well as controls, and we solved them in .NET 2.0 by having those applications use ClickOnce. Since ClickOnce applications can specify their required permissions in a manifest and allow the user to decide if this is a safe set of permissions to grant, there was no policy modification.

Orcas introduces a very similar system for IE hosted controls. They can now include a set of manifests, which are very similar to the ClickOnce manifests, that state the required set of permissions for the control to run. Again, this decouples the control from policy which solves the MSI-fight problem as well as the CLR versioning problem. Just like ClickOnce applications, these controls are hosted in simple sandbox domains -- this means that the domain and the control both have the same permission set, removing the need to assert at the entry points.

One of the first questions that comes to mind when thinking about this feature is if a control is allowed to declaratively state what permissions it wants to run with, what's to prevent malicious controls from elevating to FullTrust and doing whatever it wants to my machine? We've decided not to do any prompting of the user for this feature, instead we use a simple algorithm to determine if the control should be allowed to run with its requested permissions. Specifically, if any of these requirements are met, then we allow the control to run:

The control is requesting a subset of the permissions it would have gotten anyway. So if a control is coming from the Internet zone and it is requesting the Internet permission set, we'll allow it to run.
The control is signed by a trusted publisher. The control's deployment manifest must be signed (more on the requirements for manifests later) by a X.509 certificate. If the signer is in the client's trusted publisher list and the certificate is valid and chains to a trusted root, then we allow the control to run with whatever permissions it requests. This is likely the easiest way for IT organizations to make use of the feature, as trusted publishers can be controlled via group policy.
If the zone the manifest is running from explicitly allows controls loaded from it to elevate their permissions

If all three of those checks fail, then the control is not allowed to run. (Note that we don't run the control with the permissions it would be granted from policy if these checks fail -- we assume that the control was authored to run with the specified set of permissions, and should not be run with less than the requested set).

The third check may need a little more explanation. When you install Orcas, you'll see that a new option has been added to the Internet Explorer Security Settings dialog box called "Permissions for components with manifests":

As you can see, there are three possible values for this setting:

Disable - controls with manifests will not be allowed to run at all. Even if the control is requesting only Execution permission and is signed by a trusted publisher, if the zone it's loaded from is set to disabled the CLR will not allow the control to run.
High Safety - controls are not allowed to elevate their permissions via this setting alone. If the control is not requesting elevation or is signed by a trusted publisher than it will be allowed to run, however this setting will cause check #3 above to fail.
Low Safety (Unrestricted) - controls are allowed to elevate. Even if the first two elevation checks fail, if the zone is set to low safety, then the control will be allowed to run with whatever permissions it asks for. The reason that "Unrestricted" appears in the setting is that by setting this value, you're effectively giving all controls loaded from this zone the ability to run fully trusted. Obviously that's not something that should be done lightly if at all. [Updated 1/24/2008 - Low Safety was removed after the Orcas betas.]

Essentially, if the setting for the deployment manifest's zone is High Safety then elevation check #3 fails, if it is Low Safety then elevation check #3 succeeds. The default values for this setting are:

MyComputer	Disable
Local Intranet	High Safety
Trusted Sites	High Safety
Internet	High Safety
Restricted Sites	Disable

So no zone will elevate by default, and manifested controls are disabled entirely on the local machine and restricted sites.

Next time: More information about the manifests

ClickOnce Same Site Permissions

shawnfa — Sat, 15 Jul 2006 17:00:00 GMT

ClickOnce applications can request that they be granted permission to contact their site of origin. In Visual Studio this is done by clicking on the Advanced button in the Security tab of the project properties and checking "Grant the application access to its site of origin."

This has the effect of adding a SameSite attribute onto the requested permission set XML:

<PermissionSet class="System.Security.PermissionSet" version="1" ID="Custom" SameSite="site"> 
  <IPermission class="System.Security.Permissions.FileDialogPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Access="Open" /> 
  <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Allowed="ApplicationIsolationByUser" UserQuota="512000" /> 
  <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Assertion, UnmanagedCode, Execution, ControlThread, ControlEvidence, ControlPolicy, SerializationFormatter, ControlDomainPolicy, ControlPrincipal, ControlAppDomain, RemotingConfiguration, Infrastructure" /> 
  <IPermission class="System.Security.Permissions.UIPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" /> 
  <IPermission class="System.Drawing.Printing.PrintingPermission, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" version="1" Level="SafePrinting" /> 
</PermissionSet>

The SameSite attribute is ignored by the CLR unless we're reading the PermissionSet XML from a ClickOnce manifest. In that case, if we see the value of SameSite="site", we'll add in any appropriate permissions for the ClickOnce application to communicate with its site of origin.

So what permissions does SameSite="site" grant exactly? The answer is basically what you would expect, a WebPermission with Connect access back to the site the application was deployed from. So if your application lived on http://www.fantasticsoftware.com/KillerApplicaton/KillerApplication.application you would be given a web permission with connect access to anything matching the regular expression:

(http|https)://www.fantasticsoftware.com/.*

Applications deployed over https will only receive permission to connect back via https, and applications deployed over a non-default port will have connect access back to that port instead of the default one.

If the application is run directly from the file system, for example off of a network share, instead of a WebPermission it will get a FileIOPermission for read and path discovery back to the path it was deployed from. \\InternalSoftware\Software\AccountingApplication\AccountingApplication.application will get access to \\InternalSoftware\Software\AccountingApplication for instance.

In the event that the application already had a WebPermission or FileIOPermission in its requested permission set, then the same site permission will be unioned with the existing permission to form the final request set. You can see the final permission set by examining the DefaultRequestSet property of an ApplicationSecurityInfo object constructed with the ActivationContext of your ClickOnce application.

Why go through all this trouble instead of just hard coding the WebPermission or FileIOPermission into the manifest itself? By adding this level of abstraction, the application author does not need to know where the application will finally be deployed from. If your group builds a ClickOnce application, specifying SameSite="site" allows the IT group which is hosting the application to decide which location makes the most sense. It also gives them the freedom to move the application's location if need be without having to contact you to get the application updated.

Sandboxed Applications Can’t Elevate Their Own Permissions

shawnfa — Thu, 13 Jul 2006 21:43:00 GMT

Every once in a while someone will ask how they can do something similar to these caspol commands from within their application. Generally, they want their application to be deployed from the Internet or a file share and don’t want users to have to deal with setting up CAS policy properly to get the application to run.

The answer of course is that you can’t do this … if an application were allowed to add code groups to policy without user interaction in order to elevate their privileges then every malicious application out there would go ahead and grant themselves full access to everybody’s machine; effectively rendering CAS useless as a protection mechanism.

Instead, you’ll need to have the end user make a trust decision for you. In v1.x this was difficult, you generally had to deploy a policy MSI for the user to run or give them a set of caspol commands. With v2.0 of the CLR, we’ve made things a lot easier via ClickOnce applications. You can use ClickOnce to request any permissions that your application needs to run effectively – if these permissions would elevate the application above what it would normally get, then the user is prompted to make a trust decision.

This way your app can elevate to whatever permission level it needs, and you don’t have to worry about pushing out confusing CAS policy changes to everyone who wants to run it.

5 Reasons to Choose Simple Sandboxing

shawnfa — Wed, 19 Apr 2006 18:35:00 GMT

When it comes time to host some partially trusted code in your application, perhaps as a part of an Add-In model, you’ve got a few options to choose from. How do you decide which is the best way to go?

Thankfully the answer to this one is relatively straightforward – choose the new simple sandboxing model whenever possible. Here’s 5 good reasons to prefer it over other options:

1. It provides an effective sandbox

We’ve already talked about why using PermitOnly or Deny to sandbox code is not an effective option. The primary issue is that both of these are simply stack walk modifiers, and have no effect on the grant set of any assembly. Because of that, they can be overridden with an Assert in the sandboxed assembly. The sandboxed code (and I’m using that term very loosly in this context), won’t even have to Assert to satisfy a LinkDemand or an InheritenceDemand since those are done at JIT time and do not involve a stack walk.

In addition to being ineffective against various CAS demands, these stack walk modifiers make life much harder when it comes to protecting sensitive information. Since static variables are shared on an AppDomain level, any static state that your application may maintain needs to be protected against these “sandboxed” assemblies. If you were to create a new AppDomain to sandbox in, the shared state problem goes away because each AppDomain gets a new copy of the static data.

Since these stack modifiers obviously cannot create an effective sandbox, we’re left with two options, the legacy sandboxed domain using a v1.x AppDomain policy level, and the new v2.0 simple sandboxing API. The next four points show why it’s generally preferable to pick the v2.0 model if you don’t have to run your code on the v1.x runtimes.

2. Simpler to Create

Even for the most basic of sandboxes, a simple sandbox takes about 50% less code to create than the v1.x sandbox – and reducing the number of lines of security code in your application is goodness.

Not only are lines of code reduced, but the code itself is much easier to read and understand. The input to the simple sandboxing API is a single permission set to grant all partially trusted assemblies (and the domain itself), along with a list of assemblies to grant FullTrust (presumably assemblies provided by your hosting application).

On the other hand, the input to the legacy sandboxing API was a policy tree and some evidence. In order to figure out what permissions each assembly is going to get within the domain, you need to draw out the tree and evaluate its evidence against the policy. The same goes for the AppDomain itself. Of course, to do this, you need to understand the various evidences that an Assembly might have. Does your hosting application provide custom evidence? Does it remove or add evidence that the CLR provided? Exactly which evidence will the CLR be providing for each assembly anyway?

And, once you’ve determined all that, you’ve only figured out the maximum permission set that an assembly will have. Since the AppDomain policy level is intersected with the other three policy levels, you might end up with fewer permissions than you though.

Getting the policy tree right in the first place can also be deceptively tricky. What membership condition do you want? Which merge logic for child code groups? What parent code groups should be added?

When doing a code review, the upper hand is clearly to the simple sandboxing API on this front, since it’s very clear what the permission sets to be granted to each assembly are. In the legacy model, you can’t determine that just by looking at the code alone, since you’ll need to know the evidence granted to every one of the assemblies to be loaded into the domain.

Due to the potential complexities involved, getting the policy tree correct can be difficult, whereas setting up a simple sandbox is relatively straightforward.

3. Simpler to Understand and Reason About

I touched on this a bit in the previous point. The “simple” in the simple sandboxing API isn’t just about the code needed to create the domain. It’s also about making it easier to reason about the domain and code that runs in it.

Since a legacy sandboxed domain can have arbitrary policy, with arbitrary grant sets to every individual assembly loaded into it, you run into several complexities. The first one is just making sure that you’ve actually correctly calculated the grant set for each assembly. You also need to make sure that whatever evidence that you supplied the AppDomain will provide a secure enough backdrop for any demands that happen to hit that boundary.

Assuming that you’ve got the various grant sets of the assemblies figured out, you now have to keep each of these sets in mind when coding and reviewing any code that runs in the sandbox. Does it work correctly when called by each of the other permission sets floating around? Any code that’s being called by code with a lower permission set needs to be designed and written so that it cannot be tricked into elevating the lower permission set to its own permission set – something that can be surprisingly tricky. (Although transparent code helps you out a ton here).

When you use the simple sandboxing API, you’ve got exactly two permission sets floating around your domain, the sandboxed permission set and FullTrust. (Of course, nothing is preventing you from making the sandboxed set FullTrust so that you have only one set, although that’s not really sandboxing as much as separating code for reliability’s sake). Having just these two permission sets means that you know the core set of code which needs to worry about elevation attacks. It also means that you know the backstop of the AppDomain boundary is a secure one for your domain.

4. Resilient to Policy Changes

Since in the legacy sandboxing model, the final permission set was determined by intersecting all four policy levels, some applications would make policy decisions in a level other than the AppDomain level. Depending on your application, this might have been the only choice for you – VSTO is the canonical example here.

The problem comes into play when you realize that the other three policy levels are shared resources for the machine, and there could be contention over them. For instance, on popular way to create and deploy modifications to policy is to have one of the developers use the MMC snap in that ships with the framework SDK to create a policy MSI file.

These MSI files are snapshots of the current state of policy however, and contain no merge logic at all. This means that if two applications deploy policy in this way, the last one to install wins; the first application will have its changes removed from the system. If that application was not written with this situation in mind, it probably will fail with unhandled SecurityExceptions, causing a less than ideal user experience. In fact, given that the first application might not be run for some time after the second is installed, it could be very difficult to trace back the cause of failure!

IT departments also run into this problem; they need to deploy policy changes across the company for various internal applications. One way to solve the situation is to create one MSI file that contains all the policy changes for every application. However, that’s not ideal since users will end up with policy entries for applications they might never need to run. Another solution is to generate a script with the appropriate caspol logic; something that can be difficult to do properly.

5. Resilient to CLR Versioning

This is really a special case of being resilient to policy changes. Jessie Kaplan discusses an issue we ran into with VSTO with the v2.0 upgrade in his recent MSDN column. Since VSTO made its policy decisions in the v1.1 security policy, and security policy is tied to a specific version of the runtime, when v2.0 was installed on a machine all of the VSTO policy modifications were essentially lost to it.

Your application can protect itself against this issue by providing a config file that directs it to bind against one specific CLR instead of floating forward to a newer compatible version. This does provide a requirement that the users of your application keep the older CLR around, and may cause more pressure on you to provide a newer application built against the newer runtime.

Both of the above issues are solved for standalone applications with the advent of ClickOnce in v2.0. Now trust decisions are tied to the application, instead of the CLR version or the specific policy. If one application installs, it’s not going to affect the trust decisions for any other application on the machine. Administrators can still exert some control over these trust decisions by using a set of registry keys to control the trust manager. It’s no coincidence that under the covers, ClickOnce is using the simple sandboxing model to ensure that its applications get run with exactly the permissions they require.

Debugging a Partial Trust ClickOnce Application

shawnfa — Tue, 28 Mar 2006 20:05:00 GMT

Although the theory is that by the time we deploy a finished application it's already fully debugged we all know that in practice things rarely go that smoothly. So what happens if you deploy a partial trust ClickOnce application that starts to crash when it's run? Well, if you're lucky enough to have the problematic application stay alive for as long as it takes you to attach a debugger you're golden.

However if the crash occurs somewhere along the startup path, or if the debugger shows that something went wrong and got you into a bad state before you could attach it you might want to have the debugger run before the process even starts.

That's where things start to get tricky -- since ClickOnce is responsible for starting up your application, you can't just tell it to run the debugger for you. Instead, you can use the gflags tool from the Debugging Tools for Windows to intercept the start of your process. For a partial trust application, AppLaunch will be the real entry point, so you'll want to launch your debugger when AppLaunch starts.

In the gflags Image File section, set AppLaunch.exe as the image, check the debugger box, and put the full path to your debugger in the debugger field. I tend to use either Mdbg or WinDbg for this, depending on what kind of error I'm debugging.

Once you've got that setup you can launch your ClickOnce application normally and the debugger will start ready to run the application. If your app no longer starts up, make sure that the full path to the debugger is correct, since if Windows fails to find it, it will fail the CreateProcess for AppLaunch as well.

Finally, when you've solved the problem, you'll probably want to go back to gflags and uncheck the debugger box so that your partial trust applications no longer run under the debugger.

A couple of quick notes on this -- since all partial trust code runs through the same AppLaunch entry point, setting this up will cause all partial trust ClickOnce apps to run under the debugger, not just the one you're debugging. The same technique can be used for a FullTrust ClickOnce application as well; in that case you'd use the name of your application's .exe file instead of AppLaunch.

Detecting that You're Running in a ClickOnce Application

shawnfa — Fri, 20 Jan 2006 18:00:00 GMT

In my last post, I mentioned that application scoped isolated storage only works if you're running in a ClickOnce application. That begs the question -- how do I tell if I'm currently running in the context of a ClickOnce application?

You can see if a ClickOnce application is running in the current AppDomain by checking the AppDomain.CurrentDomain.ActivationContext property. If that value is non-null, then the domain is running a ClickOnce application. The ActivationContext will also get you the name of that application.

What you choose to do with that information is up to you. In general, modifying your behavior depending on the context of the application leads to difficult to test and debug programs. However, there may be situations (such as choosing an isolated storage scope), where having this information is necessary and useful.

Isolated Storage and ClickOnce

shawnfa — Wed, 18 Jan 2006 21:29:00 GMT

Isolated storage introduced a new scope in v2.0 of the CLR to work with ClickOnce applications. Application scoped Isolated storage is backed by the application's data directory. This enables scenarios where your isolated storage data will flow forward with your application as ClickOnce updates it to new versions.

However, in order to take advantage of this, you need to be sure you're using the application scope. The default IsolatedStorageFileStream constructor will actually use domain scope, even if you are running in a ClickOnce application. (One design decision we could have made might have been to detect if this is a ClickOnce application and default to application scope, however this would lead to the situation where the program would have subtly different behavior if it was run as a standalone application.)

Since the default constructor is using domain scope, you might observe that as your application upgrades it appears that the files you stored in your isolated storage disappear. Because of this behavior, you'll want to specify that you'd like to use application scoped storage instead of domain scoped storage:

IsolatedStorageFile scope = IsolatedStorageFile.GetUserStoreForApplication();
using(IsolatedStorageFileStream stream = new IsolatedStorageFileStream("data.dat", FileMode.OpenOrCreate, scope))
{
    // ...
}

Note that application scoped isolated storage is only available if your program is running as a ClickOnce application. If it is not, you'll get an IsolatedStorageException when you call GetUserStoreForApplication which says "Unable to determine the application identity of the caller."

Why Can't I See My Partially Trusted ClickOnce Applications in Task Manager?

shawnfa — Thu, 01 Dec 2005 00:55:00 GMT

If you're developing a partial trust ClickOnce application and are looking for its process in Task Manager or Process Explorer, you might be surprised that you can't find it listed anywhere. What you will see however is a process named AppLaunch.exe. AppLaunch is a small shim tool who's entire purpose in life is to turn around and invoke a ClickOnce application. The trick here is that it doesn't invoke the application by executing its .exe. Rather, it acts as a simple CLR host, and uses the hosting APIs to transfer control to the application's Main method. (This is one of the reasons that ClickOnce requires the application entry point be a managed assembly).

So why all the fancy redirection? It turns out that when you tell Windows to start a process, lots of things happen under the covers before the process actually gets started up. For instance, the application might be registered to use an AppCompat shim. Or it might have a registered debugger. Or there could be a .local file, which affects loading behavior. Any of these things (or plenty of others) could be controlled by the name of the application's entry point. So, to work around these issues we don't allow partially trusted applications to control the name of their entry point. Instead, they all have a main module named AppLaunch.

Since AppLaunch really just helps to protect against partial trust applications abusing something in the load path, it isn't used to launch a FullTrust ClickOnce application. Those will show up in a process list as you would expect.

As a side effect of this, if your partial trust application happens to throw an unhandled exception, it will propagate up as an unhandled AppLaunch exception since to Windows, it looks as though AppLaunch is the entry point. When you see one of these errors, it's worth attaching a debugger to the AppLaunch process and obtaining a stack trace of the exception to determine if it is a real bug in AppLaunch or if it's simply a bug in the program being run.

Using Add-Ins with a ClickOnce Deployed Application

shawnfa — Fri, 16 Sep 2005 22:01:00 GMT

One of the attendees at the PDC had an interesting question combining ClickOnce and Add-Ins. Basically, his application was being deployed with ClickOnce, and was running without elevating it's privileges beyond the Internet zone [fan-tastic :-)]. The problem is that the application was extensible with AddIns, and the identity of these AddIns were not known at deployment time.

The obvious solution is to simply deploy the AddIns with the application, and late bind to them. However since ClickOnce requires that all of the files being deployed be listed in the application manifest, obviously not knowing the identity of the AddIns until runtime prevents this solution from working.

This leaves two viable options, using Assembly.LoadFrom(string url) to load the assemblies off of the deployment server at runtime, or creating a cache of assemblies in Isolated Storage and loading them using Assembly.Load(byte[]). There are trade offs to using these two techniques, so lets look at each individually.

First, a limitation that applies to both of them. Running with the Internet permission set is going to require that the location of the AddIn assemblies be the deployment server (since you'll only have WebPermission back to the site of origin). If that's not a possibility, you'll need to add WebPermission to the server holding the AddIn assemblies to your manifest, which will end up causing your users to get a ClickOnce trust prompt.

Using LoadFrom(url) is going to be the easiest option, as Fusion will simply connect to the server and obtain your assembly for you, caching it locally. It will also automatically pick up updates to the AddIn when they are detected. However, you run into the potential problems with using the LoadFrom context. On the plus side, you won't have any limitation on the total size of the Add-In assemblies.

As an alternative you could connect to the AddIn distribution server yourself, which allows you to implement your own downloading, caching, and updating policies. However, this method also requires that you implement your own download, caching, and updating policies :-). If you want this level of control, downloading the assemblies into Isolated Storage, and then loading them with Load(byte[]) is your best bet. Using application scoped Isolated Storage for the cache means that ClickOnce will migrate your AddIns forward as you provide upgrades to your application. And since you're using Assembly.Load instead of Assembly.LoadFrom, you end up using the standard Load context.

The major limitation here will be your Isolated Storage quota, which for the Internet zone is limited to approximately 500 kilobytes. That 500k needs to be shared among all the cached AddIns and any additional streams that your application creates in IsoStore. If that won't be enough space, then you've got a few options. First you could simply not cache the assemblies, and just read them from the server every time (perhaps relying on a proxy to cache for you), and passing the read bytes directly to Assembly.Load(). Obviously this method is going to result in potentially unacceptable load times for AddIns, especially if they're contained in large assemblies or your connection to the server housing them is slow.

A second alternative is to simply use an aggressive caching cleaning policy -- simply clear out older AddIns when a new one becomes available that won't fit in the remaining IsoStore space. This method will work relatively well, though depending on your cleanup policy, you may end up causing performance problems for your users again.

Finally, you could simply let the user manage the Add-In cache. Depending on how fancy you want to get, you could give them UI to mark certain AddIns as "never cache" or "always cache". Providing a view of what is already in the IsoStore cache, and the ability to remove specific AddIns would be useful as well. With that infrastructure in place, when you download an assembly that won't fit into your IsoStore cache, you could prompt the user and give them the option to not cache this assembly or to remove some other assemblies from the cache to make room.

Basically, the answer is that this scenario will absolutely work, although you may have to do some work in order to get it up and running. Here's a quick rundown of the pros and cons of each method:

	LoadFrom(url)	Load(byte[])
Pros	Fusion cache management Fusion picks up updates automatically Quickest method to get running No built in size limitations on the AddIns.	Custom download, cache, and update management ClickOnce migrates cache up to new versions of the application as they become available
Cons	AddIns must be on deployment server Assemblies end up in the LoadFrom context You don't own the cache policy, so assemblies may be removed when you don't want them to be	AddIns must be on deployment server More work -- custom cache, download, and updating logic must be written. Cache clean options may also need to be written to present to the user Limited cache space -- ~500 kilobytes for your AddIn cache and other Isolated Storage to share

[Updated 11/4/2005: Removed wrong load context]

PDC '05: Lunch with Apple

shawnfa — Tue, 13 Sep 2005 23:01:00 GMT

Just got back from lunch with a group from Apple. After checking the rule book, it turns out that no physical laws would be violated by having Apple and Microsoft so close together, and than fully there was no matter-antimatter reaction :-).

They were interested in Avalon, erm ... Windows Presentation Framework, which was not really surprising. More interesting was their interest in Indigo, erm ... Windows Communication Framework.

Outside of that, so far there hasn't been a ton of questions about CAS, however we've answered several questions about ClickOnce. The Smart Client story really seems to be interesting to people ... and I'm pretty excited about that since I think the combination of WinForms + ClickOnce for now, and later on ClickOnce + Windows Presentation Framework can make for pretty compelling applications without the annoyances of web based applications.

A Closer Look at the Simple Sandboxed AppDomain

shawnfa — Tue, 09 Aug 2005 22:02:00 GMT

Yesterday we took a look at Whidbey's new Simple Sandboxing API. At first glance this API does seem relatively simple, however when you start to look closer at the AppDomain that is created for your sandboxed code, there are a few surprising properties.

You might expect that under the covers this API is doing the grunt work of creating an AppDomain policy level which grants AllCode the specified permission set, and then has a code group for each strong name specified on the FullTrust list in order to provide those assemblies FullTrust. However, this is not how the API works -- it actually uses an entirely different security model than the traditional policy level based one. In fact, there is no AppDomain policy level in the sandboxed domain at all! Instead the sandboxed domain simply keeps track of a set of FullTrust assemblies and a permission set to be granted to all other assemblies and the AppDomain itself. No policy resolution will be done for assemblies loaded into this type of domain.

Why does Whidbey add this second AppDomain security model? Aside from making it trivial for applications to sandbox untrusted code, it's also required for the ClickOnce security model. ClickOnce allows an application to specify the exact set of permissions it should run under. ClickOnce application authors test their applications with these permissions and expect to have exactly their requested permissions at runtime. This AppDomain security model allows for that to occur.

Similarly, Visual Studio's debug-in-zone feature also requires an environment where the permissions it requests are exactly the permissions it gets -- if it were to debug your application with fewer privileges, debug-in-zone could lead to a lot of confusion when operations that are expected to pass start throwing SecurityExceptions.

Finally lets take a look at that evidence parameter to the CreateDomain API. Since a sandboxed AppDomain does not resolve policy and always has a domain permission set equal to the grant set of the assemblies loaded into it, why does it need Evidence? Technically the domain itself doesn't need that parameter, and it won't ever look at it directly. However, the evidence is still stored on the AppDomain's Evidence property. This means that other features which make decisions based upon AppDomain evidence (such as isolated storage), can still work with code executing in a simple sandboxed domain without modification.

Configuring the TrustManager

shawnfa — Sat, 25 Jun 2005 04:42:00 GMT

I've been working on the CLR side of ClickOnce pretty much from the beginning. In fact, since I started working with it, I can count at least 3 major design revisions and countless minor tweaks. I believe that of all the people on the CLR team, I've been the one involved with ClickOnce the longest by about a year. So needless to say, I'm pretty excited to get this technology out into the world when we ship Whidbey.

Dominick Baier has a post about using GPO to tweak the behavior of the default TrustManager that ships with Whidbey. The TrustManager (System.Security.Policy.TrustManager in System.Windows.Forms.dll), is basically the UI that walks you through the process of making a trust decision. You can read more about it in Brian Noyes' MSDN article about configuring trusted publishers.

After a series of posts I have planned for the next few weeks, I should spend some time discussing the aspects of ClickOnce that belong to the CLR itself.

More information about ClickOnce can be found in the blogs of Mike Sampson from the VB team, and Saurabh Pant from the Fusion team.