ClickOnce and Security

From reading some of my other posts, you can see that most of the information available
on ClickOnce is about the deployment features — generally skimming right over the
security features.  I’d like to point out one of the security features of ClickOnce
— permission elevation.

Permission elevation allows a ClickOnce application to specify that it would like
to run with a specified set of permissions, and it can be granted these permissions
without the need to have the user modify their policy.  For instance, if I wrote
an RSS aggregator, it would need to have permission to contact multiple websites. 
Under .Net version 1.1, if this application was run off of my website, it would not
have enough permission to do this, and would be a relatively useless application. 
The only options I would have would be to provide explicit instructions for the user
to modify their security policy (not very user-friendly), provide a .msi file with
a modified security policy allowing my app to run (bad user experience, and could
be wiped-out by other policy .msi installs), or write an installer to copy my program
to their local drive (making updates difficult).

Enter ClickOnce.  Once I finish my project in Visual Studio, I can right click
on it in the Solution Explorer, and choose the Publish menu option, which starts a
wizard to publish my newsreader as a ClickOnce application.  I can choose to
publish it directly to my website, and Visual Studio will go ahead and copy the necessary
files there, as well as create two manifest files, one ending with .deploy the other
with .manifest.  Inside .manifest file (which is just an XML file), there is
a TrustInfo section, which contains the permission set that my application would like
to run under.  This permission set is an XML permission set, the same that is
used throughout the .Net framework.  By modifying this permission set, I can
change which permissions my application needs to run, so in this instance, I might
create a permission set with UI permissions, NetPermission, and maybe some File IO
permissions.  On my website itself, I provide a link to the .deploy file, which
the user can click to install my application.

Once the user clicks on this .deploy file, the security system sees that my application
is requesting more permissions than a normal application from the InternetZone would
receive. It then invokes a trust manager to determine if this application should be
allowed to have this extra level of trust.

The trust manager is a pluggable piece of this system. It implements the ITrustManager
interface, which is responsible for determining if ClickOnce applications
should be allowed to receive these elevated permissions. The trust manager for
the system is chosen in the %WINDIR%\Micrsoft.Net\Framework\<version>\config\applicationtrust.config
file. The trust manager is what users will perceive as the UI portion of the ClickOnce
install — We will be shipping a default implementation in Whidbey (System.Security.Policy.TrustManager
in System.Windows.Forms.dll), which most users will never have changed on them.

Once a trust decision is made by the trust manager, it is stored in a trust decision
cache.  Each user sees two of these caches, there is one for the entire machine,
and one for each user.  This allows a computer administrator to install an application
for everyone to use (placing the trust decision in the per-machine cache), while each
individual user can make trust decisions about applications independently.

When the user tries to run the RSS aggregator, the security system still has to provide
the extra permissions that the application requested.  This is implemented
through the use of a new code group that has been added to the default security
policy, the ApplicationSecurityManagerCodeGroup.  Basically this code group checks
to see if an assembly is part of an application, looks in the trust cache for a decision
about that application, and applies whatever permissions the app requested. 
Since this permission set will be intersected with the other code groups in the policy,
the net effect is that the application gets extra permissions.

Comments (1)

  1. Mark Levison says:

    Click Once Permission Elevation – a good start, but…