K. Brown pulled together a number of examples where fully trusted code can skirt around CLR security features, starting each with a question that seems to have an obvious answer.
CLR: Beware of Fully Trusted Code
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
MSIL in unsafe mode allows for pointers. So of course you can have security problems if you allow unsafe code. That is why it is called unsafe. C# in unsafe mode is basically C++ with simpler semantics and garbage collection.
Verifying code gets done for a reason. To ensure type safety of the stuff that gets on the stack, among other things. If you disable verifying (which you can also do for the java vm), you can convert an int to an object reference and thus have pointers.
And the reflection of private properties example is totally ridiculous. There is a permission for this, so if you do not grant that permission, you do not have a problem. In many cases such as IDEs reflection on private class members can be very useful though.
The ability of fully trusted code to do things without being security checked should not be surprising. This article serves to demonstrate this fact to people and developers with some examples.
Microsoft is moving away from letting everything run with permission by default and it’s starting with XP SP 2. In the article’s conclusion the author states that in future versions of windows, even “locally installed code may not run with full trust”. They’re probably starting to try and change developer’s mindsets to adapt to their new security policies.
Try understanding the .NET framework before you open your ignorant mouth to spout off anti-MS statements.
-G
Author: My challenge to you is to learn to write code that runs in a partial-trust environment.
I agree with the author completely, and I imagine that some people coming from C++ or even VB 6 need a little helpful reminder on this. But those of us with a solid Java back think this is a no-brainer. Well we aren’t the target audience so we should give the author some slack.
Re Anonymous: After reading this code only a Fool would run Microsoft software.
Thanks for sharing you insights, I was going to buy Whidbey but your thoughtful and well articulated post has made me think about MS in a whole new way. I only wish more posters were like you. NOT!!!
The open source fan like Anonymous love open source a lot but the fact is his mind is strictly close not like open source:P
There are too many open source advocates that are too closed minded to consider the merits of closed source.
Fortunately, the converse is not true.
if it’s so badly implemented.
The article says that you may end up trying to get full permissions in cases that you may not even know about (when you compile with /unsafe). Not only is this another possible way for bugs to creap into your system, but it creates yet another hole for bad code to get in your system.
I think that C# is a good extension of the platform and probably necessary because just adding the features that C# has to C++ would be nigh impossible without mangling the language. So it’s much better to just redefine it completly. However, it seems to me that the whole ‘security’ aspect of the language was not ready and I don’t think that they will be able to just ‘tack it on’ later.
Java’s security is different because they designed it to run in a ‘sandbox’. Though it was not designed from day one that way (which is why there are problems with things like clone()) and it has paid it’s price for that. It’s still not ‘simple’ to handle security and there are also holes in Java’s security. However, the freedom that C# has is much greater and thus the holes are much wider. I don’t think there will be many trusted C# apps for awhile.
Is this bad? That’s debatable.
FYI, .NET has direct equivalents of Java’s security policy options (which allow you to sandbox programs). Basically, it’s all the same as in Java. Running code marked as “unsafe” is a privilege which can be taken from the .NET program with .NET’s sandboxing.
“Java’s security is different because they designed it to run in a ‘sandbox’.”
Maybe so. But I’ve never used a Java app that made use of this capability. From Eclipse to Jedit can you name one?
For desktop apps sandboxes don’t make much sense. Specially if the way to configure them is with obscure (to end user) security.properties files.
However, I can imagine a future where desktop applications will have some of that sandbox features in a easy manageable way. For example a Word Processor could only have the capability to read stuff in “My Documents” and its installation directory, and only write in “My Documents” (or the equivalent for a unix box). It will also be restricted from making, say, any internet connections.
We would need a generic configuration scheme for all apps in order for this to be usable.
Why is Microsoft in the Language writing business?
When Microsoft started out, its only product was programming languages, BASIC at any rate. I also seem to recall that they wrote software for traffic lights or some other similar thing.
I suppose that I could provide some links, but I’ve read this stuff before (even if I’m only half remembering the facts, it’ll point you in the right direction), so I’m not going to provide a completely free ride for you. Do your own research, preferably before you post such garbage online.
As to Microsoft’s historic lack of quality control, you’ll get no argument from me.
“There are too many open source advocates that are too closed minded to consider the merits of closed source.
Fortunately, the converse is not true.”
Excuse me? We don’t hear closed source people bashing OSS all day long on this very website? Is this your first time on the internet?
“Excuse me? We don’t hear closed source people bashing OSS all day long on this very website? Is this your first time on the internet? ”
Most closed-source developers I know are not virulent anti-FOSS.
However, FOSS people that blast Microsoft and her cronies come cheaper by the dozen.