CAS and Strong Names

I'm going to be writing some articles on Code Access Security (CAS). CAS is there to prevent a program from doing more than it should. The program is supposed to demand permission to perform the tasks it needs to do. For instance, if a program needs to access the registry, it should demand rights to do so. If it needs network access, it should demand rights to do so. A freecell game should not need to access the network, so it should not demand those rights. My example program for this will be MyCardGame (A .NET application).

Given these demands, the systems administrator can grant specific rights to those programs. For instance, using a "Deny All, Allow Some" security methodology, a systems administrator will deny all rights for that program, except for the ones it needs. For the example program, MyCardGame, the systems administrator will allow GUI usage, as well as Keyboard/Mouse. (S)he will then deny everything else.

Then when the user runs this program, MyCardGame, the OS will then allow it to do any GUI work it needs to do, as well as any keyboard/mouse work. It will deny everything else. Normal operation, that is just fine.

Now, suppose a malicious hacker changes the code in MyCardGame to do 'evil' tasks, such as reading the registry, the OS will deny it. That's wonderful, exactly as we expected.

Take another sample application, MyManagementApp, which requires registry access. The systems administrator knows that this program needs registry access, so it allows it. All is good, until the malicious hacker changes the code in MyManagementApp, to make it clobber values in the registry. Not good.

So how do we prevent this? The key is, the systems administrator needs to be assured that MyManagementApp is really MyManagementApp, and not some hacked version. Strong names prevent this.

A strong name is a 1024 bit RSA public/private key pair. Once you attach a strong name to an assembly, you cannot change it (without breaking the strong name). If you try changing code, without removing the strong name from the assembly, it will not let you run the app.

Note, that it is still possible to change the code. All you have to do is remove the strong name. So how does this help us? This is exactly what we're trying to prevent. With CAS, we're actually trying to prevent malicious code from doing what its not supposed to do.

When the systems administrator allows MyManagementApp to access the registry, (s)he really is allowing the strong name access to the registry. If the malicious hacker changes the code, (s)he has to remove the strong name. As soon as (s)he does this, it is no longer MyManagementApp, and therefore is not allowed to access the registry. Mission successful.

So how do we attach a strong name to our assembly? It's actually pretty easy. First, create your assembly. Once complete, go to your project settings (Right click on your project, go to Properties). In the "Signing" tab, near the bottom, there is a check box called "Sign the Assembly". Select this. Then, from the drop down box, choose "". Type in a key name, with .snk extension (I prefer strongname.snk), and optionally, a password. Press OK. Rebuild your project.

That's it. Your assembly now has a strong name, and it will continue to do so. Since you maintain control of the private key, no one else can make assemblies with this strong name. Your end-users now have a guarentee that if a project has your strong name, then it is, without a doubt, the program you say it is. They can elevate with confidence.

Friends don't let friends program as administrator

It's been a while since I wrote anything, but I came across a little gem. Michael Stiefel wrote an article about Code Access Security, or CAS. At the end of the article, he states "Friends don't let friends program as administrator." Why is that, you may ask? Well, here is a scenario. I work with a network containing thousands of users. They're all managed with a domain. Now, of course, we don't want to give administrative rights to every single user. We limit the administrators to 1-5 per unit. These administrators have two accounts. They have a user account (for using the internet) and an administrative account. For security reasons, the administrative account is blocked from all HTTP, FTP, etc.

Over the months that I've been here, I've become a remote administration buff. I hate getting out of my chair. Previously, when I was back in the states, I was logged in as an account that had administrative access to my entire unit. Now, I am forced to be on a non-administrator account, and use the "Run As..." function to perform tasks. Works all fine and great - until you run into something that you can't use "Run As..." for.

The point is that you cannot guarentee that a user will have the same rights as you do when you create the program. Jeff Atwood, in The Programmer's Bill of Rights, states that all programmers should have a fast PC, for development. However, the comments below state that programmers should not only have a fast PC, but a median PC, something equivalent to what average users would have.

A good programmer wears two hats. The first hat, is the developer. The developer writes the code, makes the magic happen. However, every developer must know their roots. Every developer started off as a user. Developers have a job because of one thing - the user. If a program doesn't have a single user - it doesn't need to exist.

That said, every programmer needs to swap between these two hats. They develop in the developer's hat... Then all testing should be done in the user hat. This ensures that you, as the developer, experience every single issue that the user would experience, including lack of administrative rights.

You cannot assume that a user has any administrative rights. When you do need administrative rights for your program, you should use CAS. CAS will let the administrators know what rights you need.

Friends don't let friends program as administrator.