[Mono-devel-list] Compatibility/testing issues with security permissions
sebastien at ximian.com
Tue Jan 25 17:29:24 EST 2005
Here are the two other (nested) issues about security permissions. Keep
the comments coming :-)
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
* 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"
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).
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
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
E.g. EnvironmentCas.cs or
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>
More information about the Mono-devel-list