ClickOnce and permission elevation prompting in the internet zone
The Decision -
With the .Net Framework V2.0 release of ClickOnce, any ClickOnce App deployed from the internet zone can prompt the user for permission elevation.
For the earlier Beta2 release of ClickOnce, prompting had been explicitly disabled for internet applications that were not Authenticode signed. We consciously reversed this decision for the final release.
This decision of Microsoft has been questioned by a few in the ClickOnce/Security community. Though they do not agree with our decision, most of these blogs do try to be balanced and put forth both sides of the argument. However reading through a few community posts generated by these blogs, I did get a sense that there was a perception that this was a change pushed into the release by Microsoft at the last minute due to pressure from a few large customers.
I plan to articulate out here more clearly our thinking behind this change and hopefully debunk this perception.
The Thinking Behind It -
Non authenticode signed Internet ClickOnce applications were prevented from elevating in Beta2 with the primary goal to get user feedback on this decision so we could make a more informed decision for the final release.
The Beta2 feedback helped us realize that it was important to have a consisitent IE security model for Managed and UnManaged exes, diverging in the model was confusing and muddled our security messaging.
We also got a strong push to enable this scenario from hobbyist/non commercial/community/open source App developers who wanted to deploy their applications using ClickOnce but could not afford (both in terms of time and money) to get an Authenticode certificate.
Let's consider the scenario below ...
Jen is a .Net entusiast and a golf fanatic. She writes a .Net Golf Handicap calculator that unfortuantely needs Intranet (Not Internet) zone permissions to run. Jen wants to share this App on her homepage with her golfing friends and would also like them to get updates as she adds new functionality to her program; ClickOnce is the ideal choice of deployment technology for her.
If ClickOnce forced Jen to have an Authenticode certificate before she could share her App she would soon be looking at other deployment options. She could decide to just write the App in native code and share the exe. The native exe (even a Managed exe for that matter) would now be downloaded and run with Fulltrust on local machine, not a big security win.
Today instead Jen can use ClickOnce to downloaded her App and run in the Intranet sandbox. She also gets to keep her app current with ClickOnce and potentially push down required updates for issues she wants patched immediately.
If we flipped the scenario around to where Jen was the author of a malicious Addware App and wanted to prompt the user from the internet zone she can very easily do it today. ClickOnce has not opened up a new security hole here. We just extent the current IE security model. There are no default scenarios where you can cause a user prompt to come up using ClickOnce where you couldn't for unmanaged Exes.
Also there have been comparisions of ClickOnce with ActiveX in the past and the fact that unsigned ActiveX controls from the internet zone are now blocked by IE has been used as an argument for pushing for similar behavior in Clickonce. ClickOnce and ActiveX are naturally two totally independent technologies, but if parallels have to be drawn we see ourselves closer to exes than ActiveX, and hence as discussed above have tried to maintain the same security expereince that currently exists for exes.
Configuring Prompting -
The current ClickOnce prompting model is highly configurable.
Enterprises can also specifically disable prompting for particular zones or they can use the trusted publisher list to whitelist their ClickOnce applications to run without prompting and disable all prompting.
[MSDN - https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/clickoncetrustpub.asp]
Comments
Anonymous
February 28, 2006
Hi,
maybe you should have referenced the original blog post to get the full picture.
it is here:
http://www.leastprivilege.com/BewareBeAwareOfClickOnceDefaultSettings.aspx
cheers
dominickAnonymous
February 28, 2006
Ah - btw - you cannot completely disable ClickOnce by zone - even when prompting is set to disabled - apps with certs from the trusted pub folder can elevate.
cheers
dominickAnonymous
February 28, 2006
Jen's scenario is why the policy was meant to eb customizable. I dont think anyone questions that. I think we question why that is being shipped as the default.Anonymous
February 28, 2006
The comment has been removedAnonymous
February 28, 2006
Dominik Thx for including the post.
And yes you can disable "ClickOnce prompting" per zone but NOT "ClickOnce". Applications signed by Trusted Publishers will still run ...Anonymous
February 28, 2006
Hey Rudolph,
Jen's scenario is one where if it was a requirement for her friends to apply custom ClickOnce policy before installing her "Hobbyist App", the scneario would have been a non starter. They would just have decided to not try her app out, prompting her to move to having them just download the exe and run locally.
After our Beta2 release we concluded that we were not really adding any security by disabling prompting for internet ClickOnce apps, for it was very easy in for malicious Apps to bring up a prompt anyway. I just use Jen here to bring forth the point that while not really adding to security we were inconvniencing a set of our customers and potentially driving them to make worse security decisions.
Anonymous
February 28, 2006
ClickOnce is a very cool client application delivery system that we shipped in V2.0 of the .NET Framework...Anonymous
February 28, 2006
With all due respect, this completely misses the point. Perhaps you've heard Rico Mariani talk about "the pit of success" which he defines as follows:
"The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail."
So now look at your scenario. Jen is a .NET enthusiast, enthusiastic to get her software out the door. The path of least resistance (the pit) for Jen is to just specify FullTrust whether she needs it or not. You say "Today...Jen can use ClickOnce to downloaded her App and run in the Intranet sandbox." but this requires more work - Jen has to debug her app in the Intranet zone and do her best to figure out what permissions she needs. Your customers security depends on Jen going the extra mile here. Multiply by a million and once again you train your user base to click OK for everything, rather than seeing a need to press OK as unusual and risky.
The pit leads to a less secure environment for everyone, especially my mother-in-law who will click "Yes" on any dialog whatsoever :)
Requiring Jen to get a certificate changes the dynamic. As you say, it's a pain for Jen to do that, so the path of least resistance is for Jen to do the right thing with CAS. Jen would learn better security habits and my grandmother would be a little safer. That is much better for your customers, even if it inconveniences Jen.
Your argument that following the ActiveX model will lead to wider adoption is specious at best. ActiveX has caused all kinds of problems for Microsoft's customers because one click gives the software carte-blanche on the machine. I think your community would prefer that you start to address this rather than continue down the same road that has brought a lot of the spyware problems to begin with.Anonymous
February 28, 2006
I forgot to add - I have shown ClickOnce to hundreds of developers over the last year and a half (ever since the MAGEUI days). The audiences I saw were generally pleased when I showed them that ClickOnce refused to install unsigned code coming from the Internet zone. Now I always see some of them rolling their eyes and groaning when I show them this behavior. Several have asked me why I bothered showing them CAS at all if it can be subverted so easily. So I'm not sure the developer community is really that enthusiastic about this particular policy decision.Anonymous
February 28, 2006
Saurabh put together interesting article around this issue. 
http://blogs.msdn.com/saurabh/archive/2006/02/28/540878.aspx...Anonymous
March 01, 2006
Jason reading through your comment it seems the part where our thinking degresses is this -
You believe the inability to prompt for elevation would have forced Jen to build a App that works is the internet sandbox.
I am assuming here Jen has doen all the due security deligence and decided the minimum security set App requires is IntrAnet - which is a very realistic assumption for a large set of Apps today.
I believe that the inability to prompt for elevation would have taken her down the path of least resistance which was to have her friends downloaded the exe.Anonymous
March 01, 2006
Saurabh - why are we even talking about Jen and her friends on myspace [err, "MSN Spaces" :) ]? "Jen and her friends" is a largely irrelevant scenario relative to "I want to sell my ClickOnce app to millions of people". Jen and her friends may think ClickOnce is just a sick cool way to distribute new versions of the Hampster Dance, but they are not going to be driving worldwide adoption of ClickOnce as a commerce technology.
Jen is considered trustworthy by her friends. They know Jen so they feel comfortable giving her code a trusted role on their machines. Jen's hippie friends would probably even be willing to add Jen as a trusted CA, at which point Jen can ask for fulltrust no problem. Jen could even send her friends an EXE that does the CA meddling. Her friends would probably be willing to run that EXE, but they're her friends.
Once Jen graduates from college and decides to pursue her fortune distributing "Happy Hampster dance: Enterprise Editiont" to a mass audience she's going to find that she can't rely on the world trusting her the way her college friends did. This is as it should be. In the Beta 2 world you forced Jen to grow up a little and pass some minimum bar of trustworthiness / accountability if she wanted internet distribution. You're doing your customers [and Jen's] a favor here by forcing Jen to either live within partial trust or get at least some minimum amount of accountability by using a cert.
If she doesn't want to do those things sure she could choose ActiveX or the updater block or write her own but presumably ClickOnce is evolving into a killer technology to where Jen will be at competitive disadvantage if her software doesn't use it. Personally I think the trust story is a big part of that.
The reason I object the final bits is that Jen doesn't have to change the habits that worked with her college dorm buddies - she can ask for fulltrust just like she used to do
and tell the world to trust her just like her friends do. ClickOnce does little to help protect users in this case, and it gives Jen little incentive to tighten up the sloppy security practices she learned as a hobbiest.Anonymous
March 03, 2006
ClickOnce seems to be great stuff and I'm excited about it. From what I know so far the security behavior seems very similar to what I see from Java applets which is IMHO the right level of prompting.Anonymous
March 07, 2006
I like to think that the unsigned ActiveX debacle was born of naiveté: you're nice guys and you thought everyone else was, too. But by now you should know that this isn't the case and make the same mistake again is unforgivable.
You claim that security is paramount to Microsoft, these days, and then you say 'we're just doing the same as we do elsewhere'. You should be striving to be better than you were before, because before, you simply weren't good enough.
I'm a .NET developer and I love some of the new stuff in 2.0 but once again, you've let the marketing guys set the rules.Anonymous
March 07, 2006
I agree with Jason. You guys should get your priorities sorted out. Security comes before Golf handicaps.Anonymous
March 07, 2006
The comment has been removedAnonymous
March 07, 2006
Yep - my aunty wants to publish something on the internet without buying a cert or knowing what CAS is, so we should let anyone publish and prompt the user to run code...
If my aunty wants to do this stuff, she should know how to do it properly rather than ClickOnce bypassing basic security concepts like internet vs intranet/trusted vs restricted.
Now this has shipped with what outwardly appears to be 'DANGEROUS' default settings, most IT departments will think this is just equivalent to allowing unsigned ActiveX controls. Have I missed the point, or has MS?Anonymous
May 05, 2006
The following links to .NET resources have been collated over time with the assistance of colleagues. ...Anonymous
June 08, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=6350Anonymous
June 15, 2009
PingBack from http://workfromhomecareer.info/story.php?id=33928Anonymous
June 18, 2009
PingBack from http://barstoolsite.info/story.php?id=7830