.NET opens up a new bag of security issues

David Gabel

If you're running Windows in your enterprise, and almost everyone is, it's likely you'll soon be involved with the .NET initiative -- if you aren't already. It's a good idea, then, to start understanding what it's all about -- particularly in the area of security.

With that in mind, I recently went to a presentation, put on by Microsoft about .NET. I was surprised to learn that most of the IT professionals in the room didn't know what the initiative was, and that was the reason they were there.

In the seminar on deploying .NET in the enterprise, one thing that struck me was the security framework of the .NET initiative, and it comes about as a result of the nature of .NET. It's important for the future of your operation that you understand what these security implications are and why it's important.

First, .NET needs a new understanding of security because of what .NET is: an initiative aimed at letting anyone communicate with any source, from anywhere, at any time. And anyone includes other machines. Thus, someone with a Linux client running on a notebook at an oil-drilling site off the coast somewhere could theoretically access data stored in a SQL Server database running on a Windows SQL server, or with an Oracle database running on a Sun server, all through the aegis of .NET.

That's a pretty impressive agenda, and I'm not here to tell you how it will all work, except that it's a function of something called the Common Language Runtime, or CLR, which is an intermediate language that is just-in-time compiled for execution as required. Once it's JIT-ed, the modules (.NET assemblies) that were compiled are available for execution, so you don't have the performance degradation associated with interpreted languages.

But it's easy to see that if you are going to let everyone talk with everyone, you have just introduced a potential security nightmare. How will you know who, or what, is coming in to look at the things you have in your enterprise? And how will your users know whether to let agents, such as Java applets or ActiveX controls do their thing or not?

Many users are like me. They have read the warnings about Internet security and not letting malicious code onto their workstations. So, for example, they (I) increase the security level on my browser to ask me if I want things like pieces of code to run when I get to a Web site that wants to download them.

That's fine, but I have no idea -- unless I know that the site is really trustworthy --whether that code is safe. Even if the site is trustworthy, the code could have snuck in under the cover of night and get me anyway. Besides, with the number of ActiveX controls that are now popping up everywhere, (visit the Microsoft site, with your browser security level set to ask if you want ActiveX controls to run or not, to see what I mean), the idea of relying on users to safeguard an enterprise from malicious code is really laughable. Getting a query on each one is a pain in the neck, but stopping them altogether can mean you miss things that you actually want to see.

Enter code-identity-based security, in the person of Code Access Security.

This is an idea that is at the heart of the security framework for .NET. Instead of just having users OK code, the software will take on some of the chore, based on a number of criteria that administrators can set up inside the .NET framework.

Code Access Security in Windows .NET checks the software according to the location it came from, a publisher's certificate on the code (if it's present), a hash value that will identify the code, and/or the path to the source of the code. The administrator can specify which of these pieces of evidence are to be checked to allow the code access to some system resource. In this way, even if the user thinks an ActiveX control is OK to run, if it doesn't have the necessary authentication as defined by the system administrator, it cannot access what it wants to.

In a similar fashion, if a user downloads some piece of code, but he doesn't have authorization to access a resource that the code wants to get to -- a database, for example -- then the code will not be allowed to access that resource.

The Code Access Security system is available in Windows XP now, and will be in .NET Server when it ships later this year.

Check out Microsoft seminars on .NET at http://www.Microsoft.com/usa/events.