ASP.NET Varying Trust Level Per-Page by Assembly?

Question

I have two web applications (pre-compiled sites), one is first-party and will run at full trust. Another is third-party and should run at partial trust (or with specific permissions).

TrustedAssembly.Web.Pages.MyPage should run in the full trust default AppDomain. UntrustedAssembly.Web.Pages.SomePage should run in a partial trust AppDomain.

Furthermore, if TrustedAssembly.Web.Pages.MyPage dynamically loads UntrustedAssembly.Web.Controls.SomeControl is it possible to run the control in partial trust and/or with specific permissions, while the page runs under full trust?

And vice versa, e.g. UntrustedAssembly.Web.Controls.SomePage dynamically loads TrustedAssembly.Web.Controls.MyControl, is it possible to run the control in full trust while the page runs under partial trust?

Update/FYI: This is .NET 4

Renaterenato

Answer 1

Doing this is likely to be a bit tricky. Here are two possible lines of thought:

The first is to run the app in Medium trust, but to place anything that you want running in full trust in the GAC, and what you want running in partial trust in bin.

Note that in your 'vice versa' scenario, the trusted control may need to perform a security 'assert' before being able to perform full trust operations. e.g.

(new SecurityPermission(SecurityPermissionFlag.UnmanagedCode)).Assert();

The second line of thought is to run the app in Full trust, but then load any assembly that you want running in Medium trust using a custom Evidence. e.g.

var evidence = new Evidence();
// Initialize the Evidence
Assembly.LoadFrom(path, evidence);

But be aware that correctly setting up the Evidence object is not for the faint of heart, and I'm not sure I would go does that path.

Not a complete answer, but hopefully some ideas that can lead to one :)

Anemometry

I like the idea of running first-party code from the GAC, but we would actively need to deny SecurityPermission assertions because the level of interaction granted is controlled by the end-user in their privacy preferences. So for instance one Control may have been granted x y and z permissions where another may only have x. Loading an assembly with evidence may be the only option. Do you have any good articles that expand on that subject a bit more - namely with regards to loading controls from that assembly and runtime/compile time implications? – Renaterenato

I can't find anything great that discusses that. The tricky part is that the assemblies are normally loaded by ASP.NET, so you don't get to call LoadFrom yourself. One option to drive the loading might be to place the assemblies in some other folder (not bin), and then use an AssemblyResolve event to load them the way you want. – Anemometry

I can add (for instance) a FileIOPermission to a PermissionSet and supply the permission set to the AppDomain.CreateDomain method, the problem is that I'm having trouble attaching to the root AppDomain's AssemblyResolve event to resolve it (assembly or type) to the "remote" instance running in the AppDomain that has the correct permissions. Any ideas? – Renaterenato

Note that I'm not suggesting doing any cross domain remoting (see Alexei's response), but just loading some assemblies differently in the same domain. You can register for AssemblyResolve when the domain start (e.g. from Application_Start). But note that I'm not claiming to have a full end to end solution here, as I have not done this! – Anemometry

This has given me a lot to think about, but I think has sent me down the right path. Now... lots of redesign and refactoring. :) – Renaterenato

Answer 2

+1 to David Ebbo - running whole app under partial trust and elevating for calls from GACed assembly is only sane approach.

Some more points to think about...

• not many classes are designed to be remoted between AppDomains. ASP.Net ones are not very remotable...
• ASP.Net controls have very many integration points with runtime. You'll need to build very interesting proxy classes to properly restrict interactions between controls and runtime to avoid potential elevations and have correct cross-domain marshalling.
• it is easy to "leak" classes from other assemblies across domain boundaries (custom loading from custom location helps to prevent "leaks" by making failures more obvious). Using framework with a lot of etensions points (overrides, events) like ASP.Net gives more chances to bring objects cross domain.
• this will not help you with running arbitrary code in your process - you declare trust (non-CLR sense) to custom code by simply loading into your process. I.e. StackOverflow is achivable by code that have just execute permissions and it will relably bring your process down.

Negligent

Agreed that using remoting between appdomains is probably not a workable approach. – Anemometry