|« Bonheur!||More about generics »|
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
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
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
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
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
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
- You can use the value
Assertof the enumeration
- You can tag a method, a class or an interface with the
System.Security.SuppressUnmanagedCodeSecurityAttributeattribute 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
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.
No feedback yet
Comments are closed for this post.