Browse DevX
Sign up for e-mail newsletters from DevX


Code Access Security in the .NET Framework

Code access security (CAS) is a new feature provided by the .NET Common Language Runtime. CAS is a security model that lets you grant or deny execution permissions to an assembly according to its "properties," called evidence, such as its strong name or publisher. CAS is completely orthogonal to classic security models that lie on the authentication-permissions mechanism based on the identity of the caller. This article is a concise introduction to this compelling and fascinating topic.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

n case you ask yourself how this security model can be useful, just consider if the Windows operating system could currently apply a CAS such that no code downloaded from the Internet as a mail attachment was allowed to run (no matter if who’s running Outlook Express is the computer administrator). Got the point? No mail virus would have ever appeared.

CAS Code Evidence
The first problem that arises when defining a security model on "block of codes" is to define the entity to apply security checks on, since code has nothing like a unique "user identity" (aka principal) as we can find in NTLM, Kerberos or any standard security model.

CAS identifies an assembly on its evidence, that is, a list of property name—property value pair that describes it. The CLR comes with a predefined set of "evidence categories" as listed in the following table


Evidence Description
Application directory The application's installation directory
Hash Cryptographic hash such as SHA1
Publisher Software publisher signature; that is, the Authenticode signer of the code
Site Site of origin, such as http://www.microsoft.com
Strong name Cryptographically strong name of the assembly
URL URL of origin
Zone Zone of origin, such as Internet Zone

Here is a sample of the evidence list that makes an assembly identity.

Evidence Category Evidence Value
Strong name Public key: 01 34 67 9A CD
Simple name: TestApp
URL http://www.microsoft.com/test/application.exe
Site www.microsoft.com
Zone Internet
Publisher <none> (no Authenticode signature)

Note that not all the assemblies have the same set of evidence since it depends on the host loading the assembly (for instance an assembly loaded from the file system will have no site evidence associated with it).

Know that some evidences are stronger then other, depending on how easy they can be tampered. For instance, the strong name evidence of an assembly is stronger then its site evidence (Websites and DNS can be hacked). It’s also possible to define custom application or system based evidence types. See the IEvidence interface on the .NET framework SDK for more info.

CAS Code Permissions
Now that we’ve assessed what we mean for an assembly identity we move on examining the kind of code permissions the CAS can deal with. We’ll then soon move to the next paragraph, where will examine how permissions are associated to code evidence.
In the table that follows you can see a list of the built in access permissions.

All the permissions in this list have a counterpart security class gathered in the System.Security.Permissions namespace. As you can see in the table, code access permissions are very grained, nevertheless, it’s possible to define your custom access permissions in the situation where built-in permissions cannot fulfill your needs. See Creating Your Own Code Access Permissions on the MSDN library for more info.

Code access permission Resource protected
DirectoryServicesPermission Directory services
DNS services
EnvironmentPermission Environment variables
EventLogPermission Event logs
FileDialogPermission File dialog boxes in the UI
FileIOPermission Files and folders on the file system
IsolatedStorgeFilePermission Isolated storage
MessageQueuePermission Message queues
OleDbPermission Databases accessed by the OLEDB data access provider
PerformanceCounterPermission Performance counters
PrintingPermission Printers
ReflectionPermission Type information at run time
RegistryPermission Registry
SecurityPermission Execute code, assert permissions, call unmanaged code, skip verification, and other rights
ServiceControllerPermission Running or stopping services
SocketPermission Connections to other computers via sockets
SqlClientPermission Databases accessed by the SQL Server data access provider
UIPermission Windows and other UI elements
WebPermission Connections to other computers via HTTP

Thanks for your registration, follow us on our social networks to keep up-to-date