Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Silverlight 4’s COM+ Automation Raises Security and Portability Concerns

Silverlight 4’s COM+ Automation Raises Security and Portability Concerns

This item in japanese

Silverlight 4 supports COM+ Automation when running as an Out-Of-Browser (OOB) application with elevated privileges. Microsoft indicated that this support is a result of enterprise customers requesting such a feature, offering as an example Office automation from Silverlight.

Justin Angel, Silverlight PM, has detailed recently how to set up a Silverlight application to use COM+ (note: link requires Silverlight). COM+ Automation works only for OOB Silverlight applications with elevated trust. Unlike full trust, elevated trust means one can perform almost all commands on a Windows computer with some limitations. For example, one can read/write to the file system but only to “My” folders, i.e. My Documents, My Videos, My Pictures, etc. A list of what Silverlight 4 can do via COM+ includes:

  • Running commands or exe files
  • Reading the registry
  • Accessing the local ODBC
  • Reading/writing to disk (with the limitations mentioned above)
  • Automating Office

Since many have considered Silverlight as another Flash player, a plug-in with limited access to the computer it is running on, letting it access COM+ has raised eyebrows. On one hand it raises security issues, and on another hand it breaks the portability to other platforms. Several developers commented on the WPF Disciples group:

Shawn Wildermuth: I can't argue with that logic. I understand why MS did this, but I still think it's a mess. COM being Windows only is a bad idea to the platform IMHO.

Marlon Grech, Microsoft MVP for Client App: Although I do agree with Shawn that adding COM+ to SL was a slap in the face to the cross-platform, write once run everywhere proposition. Even if they do add support for AppleScript, you’ll still have a spaghetti code nightmare. On the other hand… guns aren’t bad, it’s the people who use them. Right? ;-)

Jeremiah Morrill: The main *conceptual *security issue I see is that this is a mixture of "trust levels". The CoreCLR is still *not *in* full trust* mode, but any COM instance, by definition, runs outside the sandbox. I think this can be confusing to both developers and users who expect/assume one thing, but get another...which generally isn't good when you are talking about security.

COM+ Automation and running Silverlight applications at elevated trust is not considered a security issue by some because the user needs to make an install to run an OOB application and they are visibly warned that the application is going to access their hard drive. In theory, this comes down to running a desktop application like any other - however, the fear likely comes from the fact that Silverlight was supposed to be an absolutely secure browser application running in a sandbox, not a desktop application.

The other problem is portability. What is it going to happen to this feature on Mac which lacks COM+? Angel mentioned that Microsoft is investigating the possibility of supporting COM on Mac through AppleScript, adding that “if Microsoft chooses to not go ahead with Mac support in Silverlight 4 RTM, well, it’s not because they couldn’t”. As for Moonlight, Angel said:

Moonlight has had the superior security model since it first shipped. Mono supports hosting Moonlight in a GtkWidget that has full-trust capabilities. So while Silverlight has an elevated privileges model, Mono has a full trust model.

In the meantime, system administrators can configure their systems to prevent users from installing and running OOB applications that require elevated trust. Group Policy Settings offers more information on that.

Rate this Article