Loading Math.Net in partial-trust sandbox

Feb 17, 2011 at 7:02 PM

Hi - I get a SecurityException when I try to call Assembly.Load(bytes[]) on MathNet.Numerics when I try to load it from a Medium-trust sandbox.  Is there anything special I need to do to get this to work, or does MathNet.Numerics need to define the AllowPartiallyTrustedCallersAttribute?  Any help is appreciated.  Thanks!

Feb 18, 2011 at 6:42 AM

Hi,

I'll look into it this weekend.

Regards,
Marcus

Coordinator
Feb 18, 2011 at 10:26 AM

What transparency level are you using in your partial trust application? .Net 4 (level 2) or .Net 2 (level 1)?

I guess the correct thing for Math.NET Numerics (Net40 build) would be to:

  • Explicitly go for level 2 by declaring [assembly: SecurityRules(SecurityRuleSet.Level2)]
  • Making MathNet.Numerics.dll SecurityTransparent
  • Making native wrapper assemblies SecuritySafeCritical (and ensure we DO always pass correct buffer lengths over to native code, no unverified "user input")
  • Hence, do not declare AllowPartiallyTrustedCallersAttribute in any assemblies.

An alternative would be to:

  • Explicitly go for level 2 by declaring [assembly: SecurityRules(SecurityRuleSet.Level2)]
  • Marking all assemblies with AllowPartiallyTrustedCallersAttribute
  • Mark all native wrapper types and members (including overrides) explicitly as SecuritySafeCritical (and ensure we DO always pass correct buffer lengths over to native code, no unverified "user input")
Feb 18, 2011 at 2:59 PM

Thanks for checking this out.  I'm using .NET 4.0 security - level 2 transparency.  I agree that marking the assembly with APTCA or SecurityTransparent should have the desired effect.  I also agree that the native wrapper methods should have SecuritySafeCritical.

One question I have, though, is should the failure be happening where I see it, i.e. on Assembly.Load, and not when I try to call a method?  Please let me know if that is the same behavior you see when trying to explicitly load MathNet.Numerics in a partially trusted sandbox.

Thanks again!

Feb 18, 2011 at 3:02 PM

By the way, not to stray from this forum's subject matter, but is it the case that in a medium-trust context under level 2 transparency, I won't be able to load any strong-named assembly that isn't explicitly marked SecurityTransparent or APTCA? I've been pretty confused on this point.  Thanks once again.

Feb 25, 2011 at 1:41 PM

 

>Mark all native wrapper types and members (including overrides) explicitly as SecuritySafeCritical (and ensure we DO always pass correct buffer lengths over to native code, no unverified "user input")

For the SecuritySafeCritical attribute, is it sufficient to just add it on the SafeNativeMethods class? Or should it go on each extern function or a methods that call the extern function? SafeNativeMethods is a static class that contains all the p/invoke functions.

Thanks,

Marcus 

Coordinator
Feb 25, 2011 at 2:14 PM

To my understanding, all the extern functions in SafeNativeMethods are not safe from a security perspective since they do NOT verify parameters, e.g. someone could pass a length parameter that is longer than the passed arrays. Hence these functions should be SecurityCritical.

Then, the methods calling these functions but also verify all the parameters are safe, so they should be SecuritySafeCritical. This would be e.g. the members of the MklLinearAlgebraProvider.

All the other code would then be implicitly SecurityTransparent and just calling other security transparent code, or code that is SecuritySafeCritical (but not SecurityCritical).

Feb 25, 2011 at 3:16 PM

OK, got it. I'll make the necessary changes to the SafeNativeMethods and the MKL Provider/

Feb 27, 2011 at 10:21 AM

Added the SecuritySafeCritical  and SecurityCritical  attributres to the MKL provider methods and the SafeNativeMethods class, respectively.