Sandbox AppDomain cross-assembly exception handling

Question

I have some issues with exceptions in a sandboxed app-domain. The code running in the sandbox is security transparent. I have a utility dll which allows partially trusted callers, and provide functionality to the sanboxed code. Its methods are SecuritySafeCritical. All works well, until we came to exceptions.

The code running in the sandbox is protected by a try-catch block, so if ti throws it does not bring down the application.

If an exception is thrown from the code in the security trasparent dll all is well. However, if the sandboxed code calls a method in the trusted utility dll, and that code throws, the following happens:

If I am in the debugger, the debugger breaks:

An exception of type 'Blah' occurred in Trusted.dll but was not handled in user code

Which by itself is OK, but then the exception is caught by my try-catch block is not of type 'Blah', but it is:

[System.Security.SecurityException] = {"Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."}

My guess is that this "leak" of exception from a trusted assembly to partial trust code is a security issue. My second guess is that this is considered an issue because the partial trusted code in between could catch the exception, which could lead to security issues, and thus the propagation is blocked. What is not clear to me is when the framework actually tries to assert the "SecurityPermission" that causes the above exception to be raised.

My question: how should I handle this case? Is there a way to make it work in a "clean" way (exception travelling all the way from trusted - partial - trusted code), and if so how, in a secure way? (obviously I do not want to blindly assert permissions, without reverting them!)

I have a fallback solution (I record the exception in my trusted helper, throw it, catch the security exception, re-throw the original exception) but I was wondering if there is a cleaner solution that goes "with the rules" instead of bending them.

And also if my guesses about cross-assembly exception handling are correct!

Answer 1

So, it turned out it was an heisenbug , or maybe its opposite...

The problem only appears if I run my code inside the debugger. It seems that the act of breaking-on-exception and then resuming it in the debugger is not liked by the sandbox. Outside of a debugger, it all works as expected, provided that you did your homework (the assembly is trusted and added to the domain trusted assembly list, it allows partially trusted callers, etc etc..)

Another issue it is worth pointing out: if you want to save the exception and report it to the calling appdomain, the exception must be [Serializable] . System.Exception is however ISerializable , so you need to implement the serialization constructor ( BlahException (SerializationInfo info, StreamingContext context) and pass the parameters down to base()