More Debate on VSTO Security
On my previous post regarding security, I got this comment from weblogs.asp.net/ptorr:
"unfortunately if it is easy for you to get your code to run, it will be easy for attackers to get their code to run."
I guess if it's difficult for me to get my code to run, then it is difficult for me to justify spending the time to write code for VSTO. Before I get too deep into my suggestions for possible alternative approaches, let me first say that I realize that VSTO is a v1 product and has room to grow. I'm offering my comments, criticisms, and suggestions in the hope that they will have some impact on the way that VSTO develops.
The goal that underlies these suggestions is two-fold: First that .NET security should exist, and second, that it shouldn't get in my way. My suggestion would be as follows: Let the document establish permissions for the assembly. In other words, if I act to open a document that has VSTO extensions, then the document knows where the assembly is located, and should be able to check to see if it has appropriate permissions to run. If it doesn't, then the document should prompt the user to that effect, warn them of the dangers of running untrusted code, ask if the the assembly should be granted FullTrust on a permanent or temporary basis, and then set the appropriate security policy automatically. It shouldn't matter whether the document is running on the local machine or over the intranet in this scenario.
Another scenario would be to provide a security setup project for VSTO solutions. The setup program should have two behaviors: 1) to install documents on the local machine, or 2) to set the local machine up to run documents from an intranet location. In the first case, the setup program should deploy the documents to the specified location, establish the correct permission set so that they can run, and close. In the second case, the setup program should prompt the user to navigate to the assembly on the intranet that is being configured, and set the appropriate permissions.
The advantage to either of the above models is that MS can validate that the user has the appropriate Machine and Intranet permissions to perform the security changes.
I guess my argument boils down to this: if Office is going to support .NET Framework development, then make Office support .NET Framework development. There's no reason that I can see that we can't have security and deployable solutions.
As always, please correct me where I'm wrong.