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

[Sebastien Pouliot]

Hello Ben,

> 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.

No I didn't receive your emails until today. I've c.c. mono-devel.

> I'm currently implementing parts of it.

Great :)

> 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.

Because of licensing issue with my job I only work in the class library (MIT
X licensed).
There's still some things that I want to fix (mostly to please corcompare)
and _many_ unit tests are missing.
But after that I think that the runtime needs to be updated before putting
more effort into the managed classes. I.e. I don't expect to make big
commits in the short time.

> 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.

Sorry, never looked into this.

> Sorry to contact you again.

Don't be - it's interesting. Anyway I just don't answer my email when I'm
too busy ;)

> 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'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.

a simple (but very incomplete) explanation could be:

- Evidences are provided by the host of the CLR. So the mono runtime should
supply evidences when loading assembly. Same thing for XSP or any other
process hosting mono.
- Code Groups are defined inside PolicyLevel using caspol.exe (on Windows).
- Permission are present in the (source and compiled) code.

Given some evidences "CAS" can resolve the policies (enterprise, machine,
user, appdomain) so it knows what "level" (PolicyLevel) to apply to an
assembly. Now that CAS knows what you've been granted (or denied) it can use
this information for permission demands.

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