Tag Archives: Code Access Security

.NET Code Access Security – The fast version

I spoke at this months GSP Developers Guild meeting as the “short presenter”. We typically have two presentations each month — one is a short presentation and one is a long presentation. I had to cut my Code Camp slides in half, but I managed to only overrun a 30 minute presentation by say, 15 minutes 🙂 Glen Gordon was our “long presenter” today. He gave a great presentation on ASP.NET Mobile Controls. I knew the presentation material, but its always great to see people respond to the technology like they did. Glen is a beast — he gave a 4 hour long presentation at the Greenville MSDN event today too. From 1pm to 5pm today he discussed Web Services, SQL Server 2005 with end point registration, Infopath consumption of the web services and end points, ClickOnce deployment and more. He then took a quick drive over to the guild meeting to give another hour-long talk on mobile web development. It was a geek decathalon!

Thanks for the great day guys. I had a blast giving my presentation again. And I really enjoyed watching your presentations again Glen.

Old News, But Blog-worthy

There was an old article posted some time ago by James Gosling at Sun. I’ve been meaning to post about it but every time I had a spare moment, someone yanked it from me. In any case, in this article Gosling was shouting some ideas that Microsoft was breaking their Trustworty Computing Initiative’s rules by allowing C++ and C into the .NET family of developer products. Gosling was quoted as saying:

“If you look at the security model in Java and the reliability model, and a lot of things in the exception handling, they depend really critically on the fact that there is some integrity to the properties of objects. So if somebody gives you an object and says ‘This is an image’, then it is an image. It’s not like a pointer to a stream, where it just casts an image,”

Basically, Gosling wants people to feel that as soon as these products were made a part of the .NET product line, they made all other .NET code insecure due to violations of type safety.

Mr Gosling evidently hasn’t studied code access security 101. When an assembly is loaded in .NET it is verified by the CLR before it is allowed to execute. Verification is pretty extensive.

In brief, let’s consider what all happens when an assembly is loaded and executed. First off, the portable executable is validated to make sure it conforms to the PE/COEFF standard. Secondly, all the metadata is validated , making sure that all pointers have valid destinations. A symantec check looks for any sort of shinanigins such as circular inheritance. Next, the IL is verified to be valid and well-formed. As each method is JITed the code is verified to be memory type safe — looking for unsafe casts and attempts to access array indexes that are out of bounds. It probes for buffer overruns and underruns.

There is one caveat to all of this. C++ indeed cannot generally be verified. There is (currently) no way to verify type safety of code written in C++. So does this make Mr Gosling right about his statements? NO. He’s absolutely wrong — and I don’t just say that because I like pretending I know more than the CTO of a multi-national corporation. I say this because security policy in .NET by default rejects any code that cannot pass all of these verifications. To get .NET to run assemblies compiled in C++, it must have the permission to skip verification. If we look at the permission viewere in the .NET configuration tool, we can view any permission set that has the security permission selected. If we double click on the Security permission, there are several sub-permissions available to us. The one we are concerned with is the Skip verification permission. The diagram below depicts this setting in case you don’t feel like looking at this yourself.

This isn’t to say that Mr Gosling wasn’t right at all, but it does put a rather large kink in his argument that there is a HUGE security hole in .NET. Code that executes on the local machine will have this permission because by default all code running in the MyComputer zone runs with FullTrust. Full Trust includes all permissions — including the SkipVerification permission. Yes, if I’m honest with myself I have to say that is a problem, but not in the sense that someone will download code or execute something from the internet that will automatically wreck havoc on the entire type safety system. If I had one wish from he security team at Microsoft it would be to turn this feature off by default.

.NET Security No No

OK. I’m going to cover this one time for guys in the peanut gallery.

Microsoft wised up some time ago and started shipping their Windows Server 2003 product with nearly every feature, apart from logging in, turned off. This was in response to the many-fold accussations that Microsoft was more concerned with functionality than security. (one could argue that they STILL are more concerned with features, but now consider security to be one of those features). In any case, today, when you install a Microsoft server product, it will have limited features, and this is a good thing.

What isn’t good is that developers and administrators keep bypassing this security by elevating priviledges for their code. They somehow feel that its appropriate to strong name their assemblies, and then grant full trust to any code with that strong name. This is an absolute NO NO!

Lets consider this scenario.If your house had priceless valuables stored in it, you would want the best security you could afford. You would remove the standard key/lock system, and replace it with biometric readers, voice print recognition systems, and panic button fail-safes. You might place further restrictions on rooms that contain your most prized possessions in case you have a dinner party — you wouldn’t want just anyone wandering into those rooms without your permission.

The same goes for your code. Think of permissions as the valuables to your code’s household. Grant permissions only when necessary, and only when all appropriate evidence has been supplied. Put fail-safes on your code by denying access to it by any callers that have elevated privileges. When clients access your application, don’t assume they should have access to all your code. If there are portions of your code that perform priviledged operations, require the client to provide additional evidence.

You need a layered approach to security. Granting Full Trust to your strong-named code will definitely help it run whatever you want it to, but you’ll also open the doors to anyone else that finds your valuable resources of interest.