[Mono-devel-list] Code Access Security (CAS) Plans

[Sébastien Pouliot]

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