views:

651

answers:

1

Hi Stackoverflowers :)

imagine the following environment: an XBAP application running in partial trust mode (default behaviour; requiring Full Trust is not an option - but before you ask, if full trust is given to the XBAP, everything works as expected) is referencing a locally installed assembly, which is located in the GAC. To achieve this, we enable the "AllowPartiallyTrustedCallers" option to the local assembly, and also full trust is granted. (imagine this is some kind of a local connectivity counterpart)

(by the way we are aware of the security aspects of using the AllowPartiallyTrustedCallers attribute, this is out of scope of this post though, just don't care)

Now, even if our local GAC assembly has full trust (we can check this by calling Assembly.GetExecutingAssembly().IsFullyTrusted at any time), it will fail any demands (implicit or explicit) since it's called by a partially trusted caller (our XBAP). (correct me if i am misunderstanding something). Fortunatelly, we can do explicit asserts to gain permissions inside our local GAC assembly, for example:

new System.Security.Permissions.FileIOPermission(.....).Assert();

By that, we could prevent a full stack walk on demands right at this point and do any file access as we want. (again, please correct me...) This actually works perfectly! (in this case)

The problem is, we just don't do any file IO, in fact we are calling external libraries which should be able to do anything they want (and they might do a lot of stuff, accessing the registry, making web service requests, write files, call unmanaged code - in detail we don't know, but we can trust them), and prevent the demand stack walk to reach our partially trusted caller. We should be able achieve this, since everything is done from our locally installed and trusted GAC assembly. (again, please don't care about security aspects here, just assume, that we can trust the client)

Approach to solve this:

  • What we thought of first, was asserting a set of permissions (PermissionSet) to nearly any permission before working with the external library. This almost works, but it looks like at some point still a security exception occurs - either, because the external library might start more threads which fail by some reason, or because its accessing the entryassembly - in fact, we don't know.

  • Second, we tried the following ttribute

[System.Security.Permissions.PermissionSet(
  System.Security.Permissions.SecurityAction.Assert, Name = "FullTrust")]

it didn't work either.

  • Third, we thought of opening a new AppDomain, making the fully trusted GAC assembly the AppDomains entry point, and run anything inside this appdomain - any stack walk could never reach the partially trusted caller anymore - in our theory). Unfortunatelly, we're not able to achive this... Or newly created AppDomain fails even more demands, even if set up to run under "MyComputer" security zones Evidence or unrestricted SecurityPermission. I am not able to explicitly grant full trust to the whole AppDomain.

  • Fourth, using caspol is not an option. (due to deployment reasons)

Now, since this should be a lot of information, i hope you understand what we want to archive.

To get this to the point: How can a fully trusted assembly assert a complete full trust to assemblies it calls, stopping all stack walks to reach the partially trusted caller?

many Thanks in Advance

A: 

Looking at the documentation from Microsoft in regards to allowing Partially Trusted Callers to Full Trust Assemblies I do not believe that this is going to be possible to do.

You keep stressing that we need to avoid the security concerns, but in all reality, what you are trying to do with your solution is bypass essentially every single portion of the code access security system within the .NET Framework, and I'll be hard pressed to believe that you are going to be able to get a viable solution.

On top of this, I can't imagine that this process is something that really needs to be done this way.

Couldn't you offload this processing from the partially trusted caller to then pass off communications to something running locally and already trusted?

Mitchel Sellers
Mitchel, I will get back to you soon regarding your alternative solutions, as they sound good to me.What I'm asking myself though is why asserting single permissions is easy and works, but a full permission set seems not to exist. The whole solution might really sound like trying to bypass the security system but bringing it to the point (for example, creating a fully trusted AppDomain from within a fully trusted assembly) does left some questions open.Thanks for your support!
moonground.de
But remember, you are trying to create a fully trusted AppDomain from a "fully trusted" dll, BUT that dll is NOT running in full trust as it was called from a partially trusted caller.
Mitchel Sellers
I'd like to accept this as an answer, as we don't see a true solution to this problem. We were able to reduce most problems to WCF though. WCF is meant to run in fully trusted environments and [it's known that problems might arise][1] when "asserting, denying, or otherwise creating a thread-specific permission context.." (Quote) for WCF API calls.[1]: http://msdn.microsoft.com/en-us/library/bb924412.aspx
moonground.de