Patrick Smacchia

I hope to clarify hereby some CAS issues often misunderstood:

Fully trusted assemblies vs. partially trusted assemblies

From CAS point of view, there are two kinds of assemblies: full trusted ones and partially trusted ones. Full trusted assemblies are those which are granted with the standard permission set FullTrust.

By default, a signed assembly can be called only from a fully trusted assembly. This restriction prevents partially trusted assemblies to invoke any assemblies stored on your machine before its installation. Indeed, the only way a partially trusted assemblies could use an assembly stored on your machine before its installation is to use an assembly stored in GAC. Now, consider that an assembly must be a signed one to be in the GAC.

To allow a partially trusted assembly to use some core assemblies such as mscorlib.dll or System.dll, MS has provided the System.Security.AllowPartiallyTrustedCallersAttribute attribute . If a signed assembly is marked with this attribute, then the CLR allows some partially trusted caller assemblies.
Nevertheless, be aware that using this attribute on a widely spread class library may be dangerous. It is so dangerous that some standard assemblies such as System.Web.dll or System.ServiceProcess.dll are not marked with this attribute.

Another potential security hole might stem from the fact that a signed assembly which doesn’t allow partially trusted callers (let’s call it C) can still be invoked indirectly by a partially trusted assembly (let’s call it A). Indeed, A can still use a fully trusted assembly B that allows partially trusted callers and B can then use C.

The Everything permission set

Assemblies granted with the Everything permission set are not fully trusted. Another difference between Everything and FullTrust permission sets lies in the fact that the Everything permission is configurable and by default, it doesn’t take account of custom permissions.

The meta-permission UnmanagedCode

The meta-permission UnmanagedCode must be considered as a ‘super permission’. Indeed, by using win32 API or COM objects, you clearly can have access to every critical resources of your machine.

There exist some other reasons than performance issues which can motivate to suppress the stack walk check for the meta-permission UnmanagedCode. Let’s imagine how methods of the standard class FileStream are coded. They might use P/Invoke mechanism to have access to win32 API to modify files. Thus, they must trigger a stack walk to check if every callers have both FileIOPermission and UnmanagedCode meta-permission. Clearly, it can’t work like that. Being able to have access to files must not require a powerful permission such as UnmanagedCode. Thus, FileStream’s methods must somehow assert that callers don’t need to have this meta-permission. There is three ways to achieve this:

• You can use the method Assert() on a System.Security.Permissions.SecurityPermission object.
• You can use the value Assert of the enumeration System.Security.Permissions.SecurityAction on a System.Security.Permissions.SecurityPermissionAttribute.
• You can tag a method, a class or an interface with the System.Security.SuppressUnmanagedCodeSecurityAttribute attribute which indicates to the JIT compiler that while executing the method (or a method of the tagged class), it should make no security checks when making the call into the unmanaged code.

The meta-permission SkipVerification

The meta-permission SkipVerification must be considered as well as a ‘super permission’ since ‘unsafe code’ can perform some very weird stuff that won’t be checked by the CLR.

Exclusive code groups

If an assembly belongs to two or more code groups exclusive of the same policy level, it won't have any permission. By exclusive code group I mean that the if the membership condition is met this policy level will only have the permissions from the permission set associated with this code group option is on.