In the course of a couple of VSTO projects for various clients, we have come to form a point of view on one aspect of the VSTO security model that needs improvement.
As people use email as a primary form of exchanging documents (whether you like it or not, this is a reality), we have become acquainted with the aspect of VSTO that essentially stops customizations from being opened and run from an email message.
To recap, in order for a customization to run, both the document itself (.doc, .xls, etc) as well as the assemblies that it reference need to pass code access security checks.
This makes sense to a certain extent. The example that is used is an Excel sheet that has button to Add or Subtract funds. The assembly is trusted, but someone switches around which button calls which function, so the trusted assembly is still called but the document itself has been tampered with. I can see the point that a trsuted assembly can be used by a malicious document, and therefore the document itself needs to pass some of trust test.
However, this is where the model weakens. The current trust test often comes down to what zone the document is in. So if a user double-clicks a document from an email message in Outlook, it is in the Internet zone and is not trusted. However, if the user saves the document to the local hard drive and then opens it, it is trusted. You could make documents in the Internet zone trusted, but that would be probably be a bad idea.
But if the user trusts a document enough to open it from email, then why make them go through the extra steps of saving it and then opening it And if they trust it enough to save it and then open it, then presumably they would be happy double clicking it as well. In either case, the issue comes down to which user action is trusted.
In the VBA world, we were able to sign projects with a trsuted signature (e.g. from VeriSign) and the signature would be removed automatically if any code was changed. I think a model like this would be more appropriate for VSTO.
That way, whether a user double-clicked on a document from an email (which could then be trusted) or they saved and then opened (which would work now but could be a threat), we would know that the customization as a whole (document and code) are trusted. Perhaps strong-naming documents would somehow do the trick
Comments on VSTO Security Model
dklayman
Hi,
Thanks for your feedback. VSTO Security and Deployment models are definitely something that we are working on for Orcas. Please do keep providing your feedback - it is very much appreciated.
I will definitely forward your request to the team that is focused on Security and Deployment to create a blog entry explaining our approach as soon as possible.
Thanks.
HockeyNut
Lex3001 --
You bring up some good points. We too have struggled w/ the VSTO security model. While it makes complete sense why Microsoft did what they did around VSTO security, it most certainly does make everyday (normal) usage of VSTO enabled documents more difficult -- especially in a collaborative environment.
I've heard talk about streamlining/obscuring VSTO security in VSTO 3, but I'm not sure what this really means. I'd love to see someone from the VSTO team do a short blog write-up about security in the VSTO 3.
Lex, given your example above, it would be cool if somehow trust could be granted based on who the email was from (if it's even possible to do that). In many cases full trust is granted based on the location of the document -- i.e., full trust if it's stored on your computer, intranet trust if it's stored on the intranet, etc. Well in this case it would be cool if full trust was granted based on who sent the email -- i.e., if Lex3001 sends me an email with a document attached to it then I trust it.
Obviously there are some security concerns around that approach (viruses auto forwarding emails with attachments), but you get the idea. An approach like this is much more indicative of real world usage than the current VSTO security model. That being said, I can appreciate the great lengths that the VSTO team went to ensure VSTO solutions are secure and do not (by default) open up security holes on end users' machines.
Anyways, just my 2 cents...