[Mono-devel-list] RE: Code Access Security

[Sebastien Pouliot]

Hello Ben,

> I understand this all pretty well now, at least with imperative demands.
I
> think I'm right in believing that declarative is harder.

Not really different except declarative:
- are called before the method is called (much better from a security point
of view);
- must be called from the runtime (in order to be called before the method);
- are more "static" because they can't change them once compiled (e.g. a
filename must be hardcoded with it's path);

> I thought about starting to write a caspol to manipulate these policy
files
> - I'm going some dummy data in the Policy classes to proceed.  Might as
well
> build this in C#.

Sure. Without this tool CAS won't be very usable. You should try early to
separate the UI (CLI/GUI) from the policy code because (someday) both a CLI
and a GUI will be required.

> Also is there anything I should consider as to how the
> runtime should load these files,

I think the only place the files should be loaded is from PolicyLevel which
is called from SecurityManager. Some code is present in CVS for loading
policies.

> where they should be stored etc?

They are sensitive files and should be stored with machine.config (which is
another very sensitive file).

> There are
> also going to be interesting mappings between some MS permission concepts
> and those in Unix, presumably.

Yes, some permissions will be more affected than others.

> Finally, I also need to get a specification together of what exactly is
> required for CAS, and identify a point where I have the basic thing - and
> what constitutes the extensions.

CAS is pretty much a block in itself. Some work can be done around it but
sooner or later you must jump in it. Some parts won't make sense until the
other parts are also present (e.g. the class library has a lot of stuff that
won't be useful until CAS is present). However this isn't a reason to stop
doing any part of it - else we'll enter the egg/chicken problem (which BTW
was solved as birds evolved from reptiles which also comes from eggs - but
that's another recursive story ;-).

If you want a (IMHO useful) CAS subset you could implement it wrt the kind
of permissions, like:
1.	The Principal permissions
(http://bugzilla.ximian.com/show_bug.cgi?id=52693)
2.	The Code Identity permissions (applicable only to assembly)
3.	The other permissions

OTOH you could just choose an area that need to be updated/modified/tested
for CAS, like:
1.	The class library
2.	The runtime
3.	The tools

> I'd appreciate if I could hack this out
> with other members on the list...

Sorry if there hasn't been much answers yet - remember that CAS isn't
planned for Mono 1.0 release.
You can also join us on IRC if you want to talk about somes ideas / problems
/ bugs that you may have.

> Just wanted to check I'm on the right path.

I still hear you, so you can't be very far ;)


Sebastien Pouliot
home: spouliot at videotron.ca
blog: http://pages.infinit.net/ctech/poupou.html

-----Original Message-----
From: Benjamin Wootton [mailto:benjaminwootton at hotpop.com]
Sent: 20 janvier 2004 15:28
To: spouliot at videotron.ca
Cc: 'Mono Development'
Subject: RE: Code Access Security


Thanks for reply.  I'm now actively working on this, so dare say I will have
lots of questions!

> > I've been implementing CodeAccessPermission.Demand.
>
> Without some runtime support this won't be easy to do, fix or test - I
> know
> as a tried a little ;)

I understand this all pretty well now, at least with imperative demands.  I
think I'm right in believing that declarative is harder.

Thanks for the explanation of policies etc.  Presumably CAS builds up the
policy objects based on the information in the security config files:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconsecurityconfigurationfiles.asp

I thought about starting to write a caspol to manipulate these policy files
- I'm going some dummy data in the Policy classes to proceed.  Might as well
build this in C#.  Also is there anything I should consider as to how the
runtime should load these files, where they should be stored etc?  There are
also going to be interesting mappings between some MS permission concepts
and those in Unix, presumably.

Finally, I also need to get a specification together of what exactly is
required for CAS, and identify a point where I have the basic thing - and
what constitutes the extensions.  I'd appreciate if I could hack this out
with other members on the list...

Just wanted to check I'm on the right path.

Thanks
Ben




> E.g. (again incomplete)
>
> - The runtime is asked to load an assembly from
> "http://www.go-mono.com/mono.dll";
> - The runtime add an URL evidence for "http://www.go-mono.com/mono.dll" to
> the assembly;
> - The URL is then used to determine a SecurityZone (using
> Zone.CreateFromURL
> and re-using IE settings) which results in Internet;
> - The PermissionSet for Internet can then be applied.
> - If a method ask for a FileIOPermission then "CAS" will check if the
> Internet permission set and refuse the operation.
>
> However if the mono.dll had a strongname (e.g. from Ximian) a Code Groups
> could give the assembly a different set of permissions (like FullTrust).
>
> > For instance, we can define code groups and membership conditions in MS
> > at the various levels, but how do the class libraries come into it?
>
> The "CAS engine" resides in the runtime for both performance and security
> (isolation). But to make CAS extendable most of objects it works with are
> implemented in managed code (in the class library).
>
> > Do they just reflect the policy as granted by the local system, so that
> > we can work with this programmatically?  If this is the case, should
> there
> > be a PermissionSet in there somewhere representing the final grant set?
>
> That's the job of CAS to resolve it all ;) with the help from the class
> library.
> However it can be "a" final grant set - as every assembly can have
> different
> trust level inside an application domain
>
> > Any insights you can give into this would be very much appreciated!
>
> Have a look at bugzilla #52693
> (http://bugzilla.ximian.com/show_bug.cgi?id=52693). This may be easier to
> do
> (but still a big step) and make it more easier to complete CAS afterward.
>
> BTW please keep your bugzilla entry
> (http://bugzilla.ximian.com/show_bug.cgi?id=52606) updated with your work
> (I
> bookmarked it) or keep a blog about your work. It's the best way for
> everyone (not just me) to see what's happening with CAS.
>
> Cya
>
> Sebastien Pouliot
> Security Architect, Motus Technologies, http://www.motus.com
> work: spouliot at motus.com
> home: spouliot at videotron.ca
> blog: http://pages.infinit.net/ctech/poupou.html
>
> -----Original Message-----
> From: Ben [mailto:benjaminwootton at hotpop.com]
> Sent: 12 janvier 2004 03:24
> To: spouliot at videotron.ca
> Subject: RE: Code Access Security
>
>
> Sorry to contact you again.  I've been implementing
> CodeAccessPermission.Demand.  I've been trying to work out this evening
> how
> System.Security.Policy, Evidence and Code Groups fit together.  I
> understand
> them in isolation, but I'm not sure how they fit into the rest of the
> framework.
>
> For instance, we can define code groups and membership conditions in MS at
> the various levels, but how do the class libraries come into it?  Do they
> just reflect the policy as granted by the local system, so that we can
> work
> with this programmatically?  If this is the case, should there be a
> PermissionSet in there somewhere representing the final grant set?
>
> Any insights you can give into this would be very much appreciated!
>
> Thanks
> Ben
>
>
>
>
>
>
>
> From: Ben [mailto:benjaminwootton at hotpop.com]
> Sent: Saturday, January 10, 2004 11:47 PM
> To: 'spouliot at videotron.ca'
> Subject: Code Access Security
>
> You posted to mono-devel last week about code access security.  I tried to
> reply, but I'm not sure if it got through or not.
>
> I'm currently implementing parts of it.  I wanted to check we were not
> duplicating any work, and also to see if you had any insights into how you
> think this should be done.
>
> I'm currently making sure that permissions are correctly represented in
> the
> assembly metadata.  At the moment, Security permissions are just shown as
> normal custom attributes.
>
> Ben