Microsoft hosted two events about Code Access Security (CAS) and Role Based Security (RBS) in august 2008.
Mark S. Rasmussen Of improve.dk gave talks on CAS:
Jakob Tikjøb Andersen Of Cnug.dk gave talk on RBS.
I already have done some programming using role provider and other of the .NET 2.0 providers, so I will not go into them in this post.
First a little about debugging:
Mark had a sample, where he loaded a gateway assembly into an App domain.
The idea was to isolate some 3rd party unmanaged code in an App Domain, which was separated from the main App Domain – sandboxing. Now CAS could be applied on unmanaged code.
I think that the loading by default is done into the main assembly.
To verify where the assembly was loaded Mark used WinDbg and loaded it with .SOS.
… I should provide a HowTo here, later on… or in another post.
CAS – How does it work?
On CAS I am a newbie – and probably will continue to be for a while.
And not without reason.
The easy part. RBS is not replaced by CAS:
CAS don’t have more permissions than the user/account running the process. CAS just restricts the permissions more than what the account does depending on the origin and/or the content of the code. I.e. code coming from the internet don’t get File IO permissions.
If the code is unmanaged then CAS checks is skipped.
The messy part. CAS checks. There are three steps:
- Determine assembly permissions
- Optionally overrule the assembly permissions in code
- Optionally replace the above CAS security model with tranparent security.
Before you read further you might get a much better understanding of CAS here: http://www.codeproject.com/KB/security/UB_CAS_NET.aspx
1. Assembly permissions are set:
- In one code groups (CG) (i.e. LocalIntranet_Zone or a custom made group for your system) an assembly is granted one permission sets (PS) (i.e. LocalIntranet) which contains permission groups (i.e. File IO).
- The resulting grants from one policy (i.e. Machine) are the union of grants from one or more code groups which the assembly belongs to.
- The assignment of zones is done from evidence (see a list of different evidence in the bottom), which comes in two flavours:
- OS provided evidence
- User provided evidence
- The resulting grants for an assembly is the intersection of grants from all policies.
Explanation: An assembly will can only belong to one zone, so it will fall into one of the five zones above. It might also fall into one of the code groups below, where the evidence is that the assembly is in the GAC or it is in the same folder than the hosting assembly or that it is downloaded from a specific site. Yet again a codegroup can contain nested code groups. If an assembly matches the evidence of a parent then it will also be matched against its children. The total permission set will be the union of all the permission sets from the code groups the assembly matched.
Or more precisely: A union of the permissions from those Permission sets.
But that is not the whole picture:
– One code group can be set exclusive, so only the PS from this group will rule.
– And one code group can be set to be the last in the nested chain (LevelFinal), so the nested CG’s will not be matched.
A recommendation by Juval Löwy for setting CAS policies is available here: http://www.google.com/books?id=dSiuGk0RZ4gC&printsec=frontcover&hl=en&sig=ACfU3U2pC5WUQ18upFH79_bprzJrW2Cdqg#PPA464,M1
Those permissions are set in the “.NET framework 2.0 Configuration” under Administrative Tools.
The zone code groups are default. Below them I added one of each other kind of other evidence just to show them all.
Notice how Permission Set Everything displays most permissions granted. FullTrust on the other hand skips CAS checks and will also skip checks added in the code.
Notice: There are more permissions to choose from than in PS:Everything, when you create a new permission set:
Nice CAS tools is found when selecting the security top node:
2. Assembly permissions are overruled:
- The assemply permissions can be ignored or more can be required from within code either with attributes (i.e. SecurityAction.Demard, Assert) or by direct calls to security functions.
- Unmanaged code is not under CAS control (Fulltrust).
3. The above security models are overruled by transparent security.
This is model is added using atrributes [SecurityTransparent]. Silverlight and CoreClr uses this model.
- I guess one should go directly to the tranparent security model and not care about the rest. But that is only possible if you write the code yourself.
- Maybe there is still an idea in sandboxing unmanaged code in a less priveliged app domain. And again – that is unmanaged code you call yourself.
- For the servers and workstations you control, you should apply Juval’s recommendations above.
- Next time you get an CAS Access denied how will you find the cause?
First use the tool “Evaluate Assembly” optionally using the CASPOL cmd line tool.
- How does ASP.NET use CAS? There is something about some minimal trust in web.config??
- When you use the tool “create deployment package” you will get a msi package with the policy settings and probably also containg custom CAS assemblies, if you have made such ones. Is it possible to add that package into a ClickOnce installation?
- The exceptions thrown – would it be good practice to translate them to nice usermessages?
Right now I will not dig further into CAS.
- http://improve.dk/articles/dotnet/securing-dotnet-code/ – more links in this doc.
- http://improve.dk/blog/security includes:
A list of standard assembly evidence:
Custom evidence could also be provided as attribues in code. You could provide some custom evidence that limits the number of times you can use a resource.
Mark made a sample, where he set a limit of how many times a user could make the PC beep in a row. The user chose a number. If the number was too high, then an exception was thrown and the PC would not beep.