[Mono-devel-list] Code Access Security Latest!

[Benjamin Wootton]

Apologies for the wordy email, but Paolo asked for an update earlier.  The
text below explains how I understand the problem and the decisions that I
think need to be made.  Any feedback would be very, very much appreciated.

 

So far:

I have decided to cut the problem down for the purposes of my thesis to the
following 5 items, representing the core of CAS.  

 

*         A basic caspol.exe.  This writes out a default security policy,
and allows the user to add or remove permissions to a given code group.
It's not going to be fully complete, but it will be in C# so it's completely
extensible.

*         Runtime loading of security policy and calculation of final policy
taking into account the policy levels.

*         Calculating final grants to assemblies based on local policy and
evidence, and assigning these grants to the assembly objects as XML.

*         CodeAccessPermission.Demand(), CodeAccessPermission.Deny() and
CodeAccessPermission.Assert().

*         Declarative RequestMinimum, RequestOptional etc.

 

I will add more as time allows, and may carry on working on this after my
deadline.  Either way I hope to leave something useful, along with some
useful documentation so that someone else can continue my work.  For the
purposes of my thesis though (which has to be finished in 2 months!) it's
important that I have a useful subset which is achievable.

 

Something I won't be attempting as part of this project:

 

*         Declarative security demands.  They are going to involve hacking
the JIT, albeit in a simple way as described at the bottom of [4].

 

Plan:

Essentially, here is what I think has to happen.  The decisions have quite a
bit of consequence, and even if I don't end up completing this it would be
nice if they were made in the best way early on so I at least offer a good
base for someone to continue the work.

 

*         There are three security policy levels - enterprise, machine and
user.  Policies set across the enterprise supersede those for the machine
and user.  Each level has an XML .config file associated with it [1] that
describes local policy.  Caspol and the management console provide a nice
way of manipulating these files.

*         At the runtime start, there is a check to see if CAS is off, or if
full trust is assigned.  If either of those is true then we need to toggle
CAS off to prevent any overhead.  In any other situation the configuration
files have to be parsed and stored *somewhere* in the runtime.  There are
managed classes representing code groups and permission sets, but I'm not
sure if the intention is to make use of these to reflect what was in the
config files, or if we should store some representation of this in the C.
(One point of confusion - does this occur at startup, or do we call into
SecurityManager.ResolvePolicy() which can call LoadPolicyFromFile() - The
guys who wrote PolicyLevel.cs may be able to help here.)

 

So, at this point the runtime knows all about local policy.

 

*         Assemblies have evidence [0] attached to them.  

*         The goal of CAS is to use evidence to determine if any membership
conditions are met.  If any are met, then the assembly will be added to a
specific code group.  If none are met then they fall into a default code
group.

*         Associated with each code group is a permission set.  An example
of this might be code that has been Microsoft Strong Named meeting the
Strong Name membership condition, being assigned to the Strong Name group
which has associated with it a very flexible set of permissions.

*         An assembly can also request or deny certain permissions
declaratively.

*         The logic for calculating the final grant set from the requests,
denials, and evidence all seem to be encapsulated in the
SecurityManager.ResolvePolicy() method [3].  I think this needs to be called
indirectly at assembly load time.  This method returns a final grant set.

*         The final grant set can be extracted as XML [2], and stored with
the assembly.

 

At this point each assembly knows it's grant set.  At this point we can
actually start to use CAS.

 

*         Developers can demand permissions.  This triggers a stack walk.
For each item in the stack we get the assembly, get its associated
permission set as XML, and recreate the permission set.  We then ask if the
demanded permission is a subset of the associated permission set.  For all
items in the stack this has to be true, else a SecurityException is thrown.

*         LinkDemands are similar - we just only walk one step of the stack.

*         I'm not sure how to handle Deny()'s and Assertions at the moment.

*         Class libraries need to have Demands() placed throughout.
Unfortunately Microsoft seem to use imperative demands - I tried to use
reflection to look for security attributes, but none are listed.  This means
that we can't automate this process

 

Most of this last part is completed.

 

Thanks

Ben

 

[0]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconsecuritypolicyadministrationoverview.asp

[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconsecurityconfigurationfiles.asp

[2]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemSecurityPermissionSetClassToXmlTopic.asp

[3]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemsecuritysecuritymanagerclassresolvepolicytopic2.asp

[4] http://bugzilla.ximian.com/show_bug.cgi?id=52693

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040128/828d7391/attachment.html