Mono Security Manager Part II - Using Code Identity Permissions
I showed a sample which demanded a resource permission,
UnmanagedCode in order
Environment.Exit. Today I'll do something very similar with an identity permission.
If you have read
then you have seen the difference between the resource (e.g. file, registry, sockets...)
and the identity (e.g. url, hash, zone...) permissions
- aptly named
*IdentityPermission. If not the previous examples should be enough
to give you an idea ;-)
The following sample is based on the most commonly used identity permission, at least in source
This identity permission allows you to control access based on the presence (or absence) of a
digital signature on the assembly (or assemblies ).
As a first step, we need to create a new key pair for this sample. This key pair will let us sign our sample assembly later.
Next we need to extract the public key from the
identity.snk file so we can include
it in our application source code.
Now the source code...
Note: You need to replace the incomplete
PublicKey property with
the one you generated with the
The sample will only allows  the
Execute method to be executed
if the assembly has the corresponding public key.
Note that I didn't said "if the assembly is signed"! This isn't the identity
permission job to check if the identity is valid (or not). Identities are supplied
by the runtime as evidences to evaluate the security policies - so it is the
runtime job to ensure the evidence are valid before supplying them. This also
means that no cryptographic operation (e.g. signature verification) are required
each time a
StrongNameIdentityPermission is being checked.
Now we compile this sample without signing the resulting assembly. We can then execute the sample with and without the security manager.
So the security manager, if active, does it's job not to execute the
method if no public key is present in the assembly.
Now recompile the sample this time signing the resulting assembly and execute the sample (again with and without the security manager).
/keyfile switch is available for MCS (1.x) and CSC 8.x (fx 2.0).
This means that you must add
[assembly: AssemblyKeyFileName ("identity.snk")]
in the sample's source code for CSC 7.x (fx 1.0/1.1).
In this case the security manager, when active, did a stack walk, because the security action
Demand, and found out that all assemblies on the stack had the
required StrongName to allow execution of the
So far it's very much like using resource permissions, but it's not yet over...
Code Identity Permissions are rarely used with "classic" Demands (as we do in this sample).
This is because a stack walk requires all assemblies (on the stack) to succeed the security check.
In this case this requires all assemblies to share the same strongname (identity).
This may happens if you use a
Zone identity but it's unlikely to be true for most others
- like StrongNames. The reason this sample works is that only one assembly is present on the
stack when the demand is executed by the security manager.
Now that doesn't mean identity permission aren't useful - they just aren't much used with a standard (stack walk) Demand. However they are far more useful when used with LinkDemand, evaluated at JIT time, or with InheritanceDemand, evaluated at load time (both unavailable in Mono 1.1.4 but present in SVN HEAD). Something to blog on later...
 Looking forward: Fx 2.0
A very important fact to be aware is that version 2.0 of the .NET framework will be introducing a big change for identity permissions: they will become unrestricted permissions like the resources permissions. Which means that this sample, when executing on 2.0, will work even if the assembly isn't signed!
Why ? Because the application is local, so it is, by default, running at FullTrust. Full trust implies that you have unrestricted access to ressources (in 1.x) and now (in 2.0) that identity permission are unrestricted permissions, unrestricted access to identities.
This means that anyone using identity permissions as a code access control mechanisms for fully trust code (e.g. a plugin system based on strongnames for digital signature and enforced by the runtime/security manager) will loose this feature soon. And yes this also means that any (fully trusted) code can now inherit/override from (InheritanceDemand) or call (LinkDemand) into the class library - so it doesn't just unprotect your code.
Now I may not like it but this isn't as bad as it sounds. There were already ways to fool around such protections. Some (most?) people were putting too much confidence into them (hey! you're still dealing with fully trusted code). Some other (not too serious - even if they don't know it) people were even claiming to have broken .NET security because of this. Conclusion: the code is running at FullTrust so it should be and will now be fully trusted ;-).
Next stop... non-CAS permissions aren't oximorons!
2/22/2005 10:04:00 | Comments
The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.