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
Version: 1.0.0.0 |
| 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 |
