I need help understanding Silverlight 4 security

Does anyone else think Silverlight 4 security is a bit screwball?

Look at the following scenario:

1. Silverlight when set to trusted app, and run out of browser mode allows you to browse for a file using the file open dialog.
2. You require the name of the path of the file to open it up from any COM automation. For example (excel/word) but this could be anything.
3. It is impossible to get the full path of the file from the dialog because of security restrictions
4. You can however using COM FileSystemObject - do what ever you want to the users file system, including create folders, move and delete files.

So in other words, why all th开发者_运维问答e fuss about security in Silverlight, which actually hinders real business use cases, when its possible to access any file anyways using COM?

To say it another way, if a user runs a malicious silverlight app, its unlikely they'll say - oh well it was COM at fault. The COM was afterall being called by a Silverlight app.

Here is what I mean....

• User browses for file - c:\myFile.xls
• Silverlight prevents you from getting the path (for security reasons)
• Silverlight only lets you work with my documents
• Using COM you can do what ever you want to the file system in the background anyways. Including copying that file now to my documents, if only you knew the name! But besides that you can wipe any file potentially if its not in use.

In my opinion Silverlight security model is flawed, either they should have given developers full trust and allow us to run apps as if they were running locally

or

Not allowed Silverlight to access COM.

Is it just me, or can anyone else see that its a bad implementation?

This triggers security alerts:

OpenFileDialog flDialog = new OpenFileDialog();
FileInfo fs = flDialog.File;
string fileName = fs.FullName;

This doesn't

dynamic fileSystem = AutomationFactory.CreateObject("Scripting.FileSystemObject");
fileSystem.CopyFile(anyFileName,anyDestination); 

I don't agree with your point of view. The fact that you can do pretty much anything that an installed COM object will allow you to do is not a reason to modify a whole bunch of existing Silverlight code to allow you to do those same things.

Why? Because in the process of opening up that code there is also an increase chance that in some unintended way that same code could get run when the Silverlight component is not running in trusted mode. If that were to happen even once the media would all over it in a shot and Silverlight's reputation would, probably unfairly, be in tatters.

Personally I'm quite happy with the very cautious approach to security that MS are taking with Silverlight.

some Silverlight controls such as the OpenFileDialog work in both trusted and untrusted mode. These controls have been ported from previous versions of Silverlight where the new levels are elevated trust were not a consideration.

Thank you to Anthony for pointing this out.

Developers need to be aware of the definition of trust we are discussing here. Running a Silverlight application in full trust with elevated privileges IS NOT the same thing as running a local Silverlight Windows based Application. It is also far more restrictive than ActiveX.

Its possible that the trust here provided in Silverlight suits your particular business requirement. It is however likely that there are scenarios where you will find Silverlight too restrictive, its best to do your research upfront, and run code samples to ensure you can do the critical stuff, before jumping in head over heels.

Microsoft guarantees that public Silverlight API has the same behavior for both for Windows and MacOS platforms. So the functionality is many ways limited by the common denominator and technical feasibility. Please treat COM introp as a specific case addressing only Windows platform and only in full trust mode and it is not going to work the same for other platforms. So the security restrictions are valid as they are the same for both worlds in terms of API reuse.

I agree with the original poster. I think it's bad implementation. We are given a built in dialog to browse for a file, including directory structure. We can select a file and get a FileInfo object, but security prevents us from getting the FullName (directory and file name). Why? How does that improve security? What's the point of the open file dialog to begin with?

And as the original poster mentioned, with those dynamic objects, we can modify the local file system... which seems like the possible security hole.

All I want to do is read some data from an excel file... a way for my users to import excel data into the application, and the file could be saved anywhere on their machine. These are sales reps using an excel files to record orders locally until they can get to an internet connection. Who knows where they all save that file... so I'm not going to try to suggest we tell them all to store it in the same place in "my documents". I'll get laughed at if I suggest that.

It seems like it should be incredibly simple. But that "security measure" that keeps us from getting the directory the user chose from the built in open file dialog makes it so that we can't use the dialog for the purpose it was created for.

So what's the alternative? Is there a way to pick files using those dynamic objects? Do I have to write my own file selection tool using those objects that can modify the file system? Since I don't need anything but to read the file, and because I read something somewhere that we do have access to the file stream... is there a way to using the file stream to open up the file for reading using the AutomationFactory?