[Mono-devel-list] Compatibility/testing issues with security permissions
Miguel de Icaza
miguel at ximian.com
Wed Jan 26 14:10:26 EST 2005
> 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.
This is something that we encountered elsewhere: basically our
implementation would allow more things than the Microsoft runtime would
allow, and might give people a false sense of portability.
But this in particular seems to impact only a very small subset of users
(definitely none of those are using Mono today) that I think we might
want to do this as a `value add' of our implementation: remove the
check, as we do not have the unmanaged code requirement.
> * "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!
This might be also a Microsoft limitation; The question really is
whether we introduce a potential hole, and my feeling is not.
> 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
I agree, this sounds better.
More information about the Mono-devel-list