cpurick

No excuses. I've heard all about how CAS is a fact of life, but there's no reason -- none whatsoever -- that this system can't generate meaningful messages when trapping loader exceptions.

The least MSFT could do would be to tell us which assembly has inadequate evidence or permissions. There's no reason you can't tell us where the problem lies when you refuse to run our code over what amounts to a mere technicality.



Re: Visual Studio Tools for Office CASPOL / Security complaint

OmegaMan

cpurick wrote:
No excuses. I've heard all about how CAS is a fact of life, but there's no reason -- none whatsoever -- that this system can't generate meaningful messages when trapping loader exceptions.


This system mentioned...is iot VSTO or Caspol I will assume you mean VSTO.....

cpurick wrote:
The least MSFT could do would be to tell us which assembly has inadequate evidence or permissions. There's no reason you can't tell us where the problem lies when you refuse to run our code over what amounts to a mere technicality.


I am not going to disagree with the argument...for I do agree. But I also understand that VSTO is managed code sitting on an Active-X wrapper on top of unmanaged com code written going back into the nineties.

I would surmise that the reason that a more thoughtful error message is not forthcoming is that they are hampered by the Rube Goldberg way of working with office. (I would expect the VSTO team is as annoyed as the rest of us about this situation..it would cut down on Forum requests and get the technology out in the hands of more developers...).

A better question/statement might be..."In the next version of office...will the error messages relating to security be more robust."






Re: Visual Studio Tools for Office CASPOL / Security complaint

Misha Shneerson - MSFT

VSTO security is a very complicated thing and I was frustrated myself on many occasions (see this one). And I work on the team!

But let me put this thread into a more constructive direction and ask you what feedback from the security system would you like to see






Re: Visual Studio Tools for Office CASPOL / Security complaint

cpurick

Well, as I said, I think it would be nice if the loader logged details about which assemblies were being rejected, and why. This functionality could conceivably be extended to include a design-time test-loader that verifies the "loadability" of an entire deployment package.

Also, there's no reason we should have to write our own code to script caspol.exe. The install packer should be able to generate this as something that would complement the above design-time functionality.

I'll hold my tongue because I realize the VSTO team did not write this security model as much as they chose it from a limited selection, but I have serious doubts about whether all this extra effort is worth the marginal security it provides. After all, it appears that any ordinary user can pretty much give any software "full trust" permissions by simply installing it -- as long as it's strongly named. How can that be called "security "





Re: Visual Studio Tools for Office CASPOL / Security complaint

Misha Shneerson - MSFT

For the logging part - it is there - just not enabled by default. See this link:

Troubleshooting Add-ins Using a Log File and Error Messages

Visual Studio Tools for Office can write all errors that occur during startup to a log file or display each error in a message box. By default, these options are turned off for Outlook projects. You can turn the options on by adding and setting environment variables. To display each error in a message box, set the VSTO_SUPPRESSDISPLAYALERTS variable to 0 (zero). You can suppress the messages by setting the variable to 1 (one). To write the errors to a log file, set the VSTO_LOGALERTS variable to 1 (one). Visual Studio Tools for Office creates the log file in the folder that contains the application manifest. The default name is <Manifestname>.manifest.log. To stop logging errors, set the variable to 0 (zero). For information about setting environment variables in Microsoft Windows XP, see "How To Manage Environment Variables in Windows XP" (http://support.microsoft.com/default.aspx scid=kb;en-us;310519).

The "secuirty" part of VSTO security is that end-user has to make explicit decision to trust the code. Suppose, there is a scenario when someone sends you a Word document. When you open it you really do not intend that the mere fact of opening to document will execute code on your machine. So, to mitigate against this you need to make a trust decision - and VSTO have picked CAS as a security mechanism.

We are aware of the usability aspects of this security model and we are trying to improve it, but again, everything about security must be EXPLICIT. We need you to be an active participant of the security story for the component that you deploy to your customers. Security is not the right choice for "It just works" approach.

I know it is painful to have absolutely NONE tools support for deployment. This will get somewhat better in v3. But still we need to make tought choice when choosing between not allowing any trojans on the end-user machine and having developers work harder.






Re: Visual Studio Tools for Office CASPOL / Security complaint

cpurick

"The "secuirty" part of VSTO security is that end-user has to make explicit decision to trust the code."

Once we establish that all the "security" model really does is require the user to install applications, then what purpose is served by making it any harder than necessary to package installable applications

Surely you're not about to argue that the increased difficulty of building installable applications helps to deter hackers...

"Security is not the right choice for "It just works" approach."

True, but security should also be more than just requiring the end-user to install the program.  Frankly, it's an insult that I have to subscribe to CAS and carefully key my entire deployment when the truth is that any hacker can do all the same things, and that in the end the only thing that makes us secure is our reliance on the user to only install "good" programs.  Make no mistake: this model may protect Microsoft, but from where I stand it's mostly just programming overhead.  Show me a model where my software will work but the malware won't, and maybe it'll be worth the effort.

I appreciate the logging tips.  I will be sure to try it the next time I'm having problems with an installer.  Are you saying it will actually tell me which component/strong name key is the problem





Re: Visual Studio Tools for Office CASPOL / Security complaint

Misha Shneerson - MSFT

The log should have the complete security exception with the stack (from which you should be able to conclude which assembly failed to load and why.




Re: Visual Studio Tools for Office CASPOL / Security complaint

Misha Shneerson - MSFT

Also, I think the problem (and our mistake) is that we have projected our security system that was originally developed to protect against code executed by documents (which do not require the full installation and this security story makes more sense) onto our security story for the add-ins.




Re: Visual Studio Tools for Office CASPOL / Security complaint

mikeaerni

i cannot get a message box or log file generated, even after setting the environment variables. i can will office 2003, but not office 2007. any ideas



Re: Visual Studio Tools for Office CASPOL / Security complaint

Misha Shneerson - MSFT

Your add-in might have crashed and could be hard disabled. In this case, Office will not even attempt to load the add-in.

Check the Disabled Items list in the Add-Ins section of the Trust Center.






Re: Visual Studio Tools for Office CASPOL / Security complaint

mikeaerni

hi misha, thanks for your response.

so i have another clue for you. i haven't started googling this yet, but wanted to post this asap. my installer supports install for current user or all users. the addin works if i install for current user only, but not when installed for all users. all users does work for office 2007(excel,powerpoint,word), outlook 2003, and office 2003. the registry settings is the same comparing outlook 2007 to outlook 2003, so does outlook 2007 not support local machine addins if not, how can non-admin users install the addin

thanks!!





Re: Visual Studio Tools for Office CASPOL / Security complaint

Misha Shneerson - MSFT

Did you see this thread (http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=1294760&SiteID=1)




Re: Visual Studio Tools for Office CASPOL / Security complaint

mikeaerni

thanks for that post.

however, i was able to get my addin working for all users by removing the Manifest entry from the registry. when it wasn't working, i had all three entries : "ManifestLocation", "ManifestName", and "Manifest". by removing "Manifest", everything works!!!

according to http://download.microsoft.com/download/d/f/c/dfc24a21-1167-4579-b99c-c4df9b61deec/VSTO2005SE_Design.doc,

VSTO 2005 SE add-ins require a single Manifest entry in place of the two ManifestLocation and ManifestName entries. This entry must be with all the other standard settings under the add-in name in the standard location in HKCU. Note that if a Microsoft Office application from the 2007 release finds the Manifest key in HKCU, it has all the information it needs and does not need to perform the second registry scan in HKCR

i guess by eliminating the Manifest entry, office 2007/vsto is forced to read ManifestLocation and ManifestName, thus, providing a work-around to allow vsto to be installed for all users.





Re: Visual Studio Tools for Office CASPOL / Security complaint

Misha Shneerson - MSFT

Yes, if you remove Manifest registry key - Office will load your add-in from HKLM, but ....

By removing the Manifest reg value you essentially tell Office 2007 that your add-in should not be specially treated as a managed add-in, but is rather a regular COM add-in. Office did not apply the HKCU-only loading restrictions on COM add-ins because they of applicaiton compatibility issues (the old stuff should work, but managed add-ins concept is new to Office 2007 so old rules do not apply). However, Office wants everyone to move to the HKCU based registration.

Can I ask you why you need to install the add-in for all users on the machine (I am asking is partly out of the curiosity, partly because I want to understand the customer requirements better and possibly affect such decisions when they are made in the future)

Removing the Manifest reg value affects number of things (quoting by memory):

1. You will not be able to use ribbon customizations because your add-in won't be queried for IRibbonExtensibility interface.

2. You will not be able to add a CustomTaskPane on startup( and since you won't be able to customize ribbons - your options of starting CTPs are somewhat limited).

3. If you have multiple add-ins that are registered in the same way and one of them crashes on Startup (or Office app is killed when one of such add-ins is starting up) - all of the add-ins will be disabled because Office will disable the entry point - AddinLoader.dll. Since all such add-ins are activated through AddinLoader.dll - all of them get disabled.






Re: Visual Studio Tools for Office CASPOL / Security complaint

Sue Mosher - Outlook MVP

Misha Shneerson - MSFT wrote:

Can I ask you why you need to install the add-in for all users on the machine

Misha, I feel compelled to jump in here: Surely Microsoft understands that some customers have multiple users working on a single machine and, therefore, need to have an add-in install so that it is available to all such users.