Mono Security Manager Part III - Using Non-CAS permissions
Are there such things as non-CAS permissions ? Well I surely hope so, code security is fairly new compared to Role-Based Access Control (RBAC) or any arbitrary permission (e.g. time based). But technically the CLR doesn't make much difference of them and most differences are hidden to developpers.
So what are the technical differences between CAS and non-CAS permissions ?
- All CAS permissions classes inherits from
System.Security.CodeAccessPermission. This means they implement both the
- Non CAS permissions don't have to inherit from any specific class but must implement the
IPermissioninterface. The only example in the framework is the
PrincipalPermissionclass - a classic RBAC example;
- As non CAS permissions do not implement the
IStackWalkinterface they cannot be used to
PermitOnly(i.e. the stack modifiers). In fact they do not provoke a stack walk at all.
Non CAS permission have been working for a while on Mono. In fact this sample, with a few subtle changes, would work under Mono 1.0.x. The subtlety is that we can now use declarative security syntax (i.e. attributes) instead of using imperative security (i.e. source code).
To be used for declarative security, a permission class must have a corresponding security attribute class
PrincipalPermissionAttribute). The attribute class must inherit from
otherwise it attribute will be encoded as a custom attribute (i.e. the security manager won't execute it).
Now just to confuse things all security attributes do not inherit directly from
CodeAccessSecurityAttribute - even non CAS permissions (note that the class isn't named
CodeAccessPermissionAttribute after all ;-).
The following sample restrict execution of the
Execute method to the user named root.
Unlike my two previous blog entries, it doesn't restrict a specific
resource or something specific to the assembly
(i.e. code identity), but the user itself.
Now compile the sample, try to execute it without the security manager, then execute it with the security manager and finally execute it as root with the security manager still enabled...
So the security manager does more then just handle CAS. But CAS is so big that most people don't make any
distinction between CAS and the security manager. As I said before the framework itself doesn't help much in making
a distinction, let's try a variation: Insert a line to disable the SecurityManager just before calling the
and execute it again, as yourself and as root, with the security manager enabled...
PrincipalPermission still gets called! It's not a Mono specific behavior but don't trust me just because I wrote
this on the internet, go ahead and try it on the MS framework ;-). The "security manager" is an overloaded keyword in the CLR.
Also note that on Mono it won't work (i.e. it won't get called) if you do not enable the security manager.
This leads to an important feature, supplying the
--security to Mono means more than just turning on the
SecurityManager.SecurityEnabled property. The reverse is also true, and potentially more dangerous, not enabling the security manager
disable more security than turning off the
Q - What happens if I use a
[PrincipalPermission(...)] in my code and execute it with Mono 1.0.x or before Mono 1.1.4 ?
A - It will be ignored as any type (CAS or non-CAS) of declarative security. In fact it will also be ignore with 1.1.4 onward
if you do not activate the security manager (
Q - Can non-CAS permission be used for LinkDemand (JIT time) and InheritanceDemand (load time) ?
PrincipalPermission wouldn't be very useful, but it's still usable. Other custom non-CAS permission could be more useful.
2/23/2005 18:58:29 | Comments
The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.