[Mono-devel-list] Compatibility/testing issues with security permissions

[Sebastien Pouliot]

Hello again,

Here are the two other (nested) issues about security permissions. Keep
the comments coming :-)


* Compatibility

There are two main approach - but neither are perfect.

1. Be compatible with Microsoft's implementation as...

        * it increase the compatibility of assemblies between the two
        runtimes;
        * this is the easiest way (by a _long_ shot) from a testing
        point of view;
        
2. Do it from scratch

	* start with threat modeling and work up our own model;
	* a _lot_ more time consuming (to get quality results);


So far (i.e. the System.Environment class) has been done "as much as
possible" (!= always) using approach #1. Common sense still rules ;-)

The major problem are:

        * "Over protection" for some resources (this isn't a security
        problem but may impact performance);
        
                E.g. Microsoft's System.Reflection.StrongNameKeyPair
                implementation requires UnmanagedCode permission (maybe
                because it call an unmanaged API, maybe not...).
                
                Mono's implementation of StrongNameKeyPair is completely
                managed and the class, by itself, doesn't do much. So we
                could possibly (if the code using the class is properly
                protected!) skip the check.

        * "Over protection" can also be misleading as sometimes a
        permission is used because of it's end effect - not it's true
        meaning. A common pattern is to require UnmanagedCode because
        you only want highly trusted code to execute (yes there are
        better ways to do it).
                
                E.g. Environment.MachineName requires UnmanagedCode
                permission, while other similar properties (e.g.
                UserDomainName, UserName, ...) doesn't. 
                
                The UnmanagedCode requirement is documented (in this
                case) but it doesn't tell why it is required!

        * It is far more difficult (and dangerous) to "under protect"
        resources.
        
                E.g. A case Mono requires more P/Invoking while
                Microsoft offers a managed implementation (I don't
                recall any personally).
                
        * Differences between Windows, Linux...
        
                E.g. Blocking access to Environment.UserName _based_ on
                the USERNAME variable makes more (not totally) sense on
                Windows but I changed it to USERNAME;USER in Mono. (Not
                a very good answer as there are many ways to infer the
                user's name but that's another problem).


* Testing

My plan is to use NUnit as much as possible but, sadly, it cannot be
used in every case (e.g. non FullTrust executions). Thankfully most, if
not all, the class library security checks can be checked by using stack
modifiers (Assert, Deny or PermitOnly) before calling the tested code.

These new NUnit tests could...

* be in the same (existing) unit tests assemblies. The tests (or
fixtures) would be marked with a new [Category ("CAS")]. The CAS
category should be executed with "make run-test-ondotnet" (Windows/MS
runtime) but not with the Mono runtime (make run-test). Ideally a new
target would be added (e.g. make run-cas-test) that will executed (only)
the CAS test suites;

        +++ minimal changes to the build / Makefile (new target)

* be in separate tests assemblies used exclusively for security tests.
In this case there is no need to add a new category, but the build
changes are more complex;

        --- change to build/Makefile (new *.sources files, new folders,
        new targets and probably a lot more things I don't know
        about ;-)


Personally I don't have any problem with either solution (first one
seems simpler to me).

However I really don't want to mix (source wise) the security test cases
with the current unit test case. This is mostly to allow easier tracking
and reviews in the future. So I propose that the new source tests files
ends with Cas.cs (or CasTest.cs if something depends on tests ending
with *Test.cs).

E.g.	EnvironmentCas.cs	or
	EnvironmentCasTest.cs


Other tests (e.g. everything that can propagate the stack, the security
runtime itself, etc) will end up in a subdirectory (e.g. cas)
inside /mono/mono/tests with custom Makefiles to run them.

-- 
Sebastien Pouliot  <sebastien at ximian.com>
blog: http://pages.infinit.net/ctech/poupou.html