[Mono-devel-list] Code Access Security (CAS) Plans
Eran Sandler
esandler at netvision.net.il
Sat Jul 24 06:58:48 EDT 2004
Sebastien,
I'd like to contribute to the CAS plans.
I have extensive experience in .NET on Windows (dating back to the early
beta days of the .NET framework) and also exntesive knowledge in Windows'
APIs. I'm a bit new to programming in Linux so it will be a good oppertunity
to write some Linux code :-)
I have dealt with CAS in MS .NET and am familiar with the concepts and some
of the implementation.
I wanted to contribute to Mono a few times before but someone always beat me
up to take responsibility to a certain code part :-)
Contact me and tell me if there is anything special you think I should do,
otherwise I'll just pick up a topic from the ones you have outlined and see
what I can do to help in it :-)
Eran Sandler
----- Original Message -----
From: "Sébastien Pouliot" <spouliot at videotron.ca>
To: "Mono-Devel-List" <mono-devel-list at lists.ximian.com>
Sent: Friday, July 23, 2004 9:23 PM
Subject: [Mono-devel-list] Code Access Security (CAS) Plans
> Hello,
>
> Here's the high-level plan to implement CAS in the next releases of Mono.
> Comments and contributors are welcome :-).
>
>
> * Goals
> The first version of CAS, to be included in Mono 1.2, will
> probably be incomplete because a great deal of time will be
> required to ensure that all required permissions are placed
> correctly in the class libraries [1].
>
> Mono 1.2 goal is to include, as much as possible, a completely
> working CAS engine - which will be available as a preview
> (default to off). In order to reduce the rework required for Fx
> 2.0 features later (for Mono 2.0) they will be added (and hidden
> when required) immediately - unless they do not affect the core
> engine.
>
> Mono 2.0 goal for CAS will be optimizations and completeness.
>
>
> * Dependencies
>
> CAS relies on:
> * valid and verified assemblies - unsafe and unmanaged
code
> can
> bypass CAS (which is why they require full-trust to execute);
> * cooperation from the JIT when inlining methods (i.e.
> loosing
> stack frames);
>
> CAS also share some infrastructure with some other Fx features,
> like:
>
> * Strongnames
> * not really CAS related (but reused by CAS)
> * but completely part of Mono 1.0 either ;)
>
> * Role Based Access Control (RBAC)
> * Almost (except Windows 2003 specific stuff) complete
> wrt 1.1 API (see System.Security.Principal)
> * Only missing declarative permissions support, which
> involves decoding security attributes and producing
> appropriate code
> http://bugzilla.ximian.com/show_bug.cgi?id=52693
>
>
> * Main Work Items
>
> * Evidences
>
> The runtime must expose evidences for loaded assemblies (and
> application domains). The exposed evidences can vary by host
> (e.g. some evidences are only used for web applications - hence
> only a web server needs to supply it).
> http://bugzilla.ximian.com/show_bug.cgi?id=53548
>
> Evidences includes (in Fx 1.1):
> * ApplicationDirectory;
> * Hash (our current implementation isn't correct);
> * PermissionRequestEvidence;
> * Publisher (Authenticode);
> * Site;
> * StrongName;
> * Url;
> * Zone
>
>
> * Policy Resolution
>
> This occurs when policy files (XML) are resolved with the
> supplied evidences. This results in a set of granted (and
> denied) permissions for the assembly.
>
> Some command line tools (caspol) and, hopefully, some
> (contributed) GUI tools are gonna be needed to edit security
> policies.
>
> Most of code for dealing with policies is located in the
> namespaces:
> * System.Security
> * System.Security.Policy
>
>
> * Stack-walk
>
> Each CAS demand requires a stack walk to ensure every callers
> has the required permissions before accessing a protected
> resource. Stack walks must also deal with fun stuff like
> threads, delegates and app-domains.
>
>
> * Code Identity
>
> Code Identity Permissions are a good starting point because they
> are assembly level permissions (i.e. they do not requires to be
> implemented everywhere in all assemblies). They are also the
> most common, and most understood, CAS feature (as they have been
> in use for mobile code for many years).
>
> Code identity permissions contains "Identity" in their names and
> includes (very similar to evidences ;):
> * PublisherIdentityPermission;
> * SiteIdentityPermission;
> * StrongNameIdentityPermission;
> * UrlIdentityPermission;
> * ZoneIdentityPermission
>
>
> * Attributes
>
> There are also some "normal" (non security) attributes that
> affects code generation (JIT) and the runtime:
>
> * AllowPartiallyTrustedCallersAttribute: Add LinkDemand
> for FullTrust for strongnamed assemblies that do not
> have the attribute.
>
> * SuppressUnmanagedCodeSecurityAttribute: JIT (link)
> check but no runtime check for unmanaged calls.
> * UnverifiableCodeAttribute: Should be present when
> unverifiable code is present in an assembly.
>
>
> * Class library
>
> All other (non-identity permissions) also need to be implemented
> and used to protect their resources.
>
> Most of the permissions resides in corlib, in
> System.Security.Permissions namespace, but there are some
> Permission-derived classes in almost all other assemblies.
>
> Other classes, mainly in System.Security and
> System.Security.Policy namespaces are also required for the CAS
> engine, while others may not be CAS-related.
>
>
> * Testing framework
>
> Implementing CAS will requires far more code to test it properly
> than to implement it.
>
> * Unit tests
>
> NUnit can be used to test individual classes - outside their CAS
> usage. This includes validating IPermission's Interset,
> IsSubsetOf and Union and the XML [de|en]coding.
>
>
> * Policy-based tests
>
> Ideally a (relatively) small set of assemblies should be
> executed with different policies (resulting in different
> results).
>
> This approach may not work well with NUnit (as the results will
> be different depending of the policies). A scripted approach,
> generating XML/HTML results, is a possible alternative.
>
>
> * Guidelines
>
> Finally some guidelines will need to be published to help all
> mono contributors using CAS, even indirectly, effectively. For
> examples:
>
> * How to implement and test IPermission classes (right now
> classes have different patterns);
>
> * When/How to use the framework permissions; and
>
> * Correct use of CodeAccessPermission.Assert
>
>
> * Contributors
> As you can see CAS requires all kind of skills (JIT, runtime,
> class library, tests, CLI/GUI tools...). Some people have
> expressed interest in helping to implement CAS.
>
> * Benjamin Wootton (depends on new job)
> * Alexis Christoforides
>
> Other people are welcomed.
>
>
> * Notes
>
> [1] Because of the internal differences between the Mono .NET
> implementation and Microsoft .NET implementation, permissions will
> probably be a little different (as the resource to protect won't be
> exactly the sames). We can "over"-protect some resources to match MS
> implementation (e.g. require unmanaged code permission even if our code
> doesn't use unmanaged code) but we cannot "under"-protect resources
> (e.g. the opposite case). Otherwise CAS would be useless.
>
>
> Sebastien Pouliot
> http://pages.infinit.net/ctech/poupou.html
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
More information about the Mono-devel-list
mailing list