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 "
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.
Monday, August 27, 2007
CAS and Strong Names
Posted by
Mike Christiansen
at
10:31 PM
Labels: C#, CAS, Code Access Security, Elevation, Private Key, Public Key, RSA, Strong Names
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment