One of the reasons I started this blog was to have a permanent record of a question I used to see on the old microsoft.public.dotnet.security newsgroup about providing extra trust for an Internet Explorer hosted assembly. In that post I mentioned that IE doesn’t have the strong name or Authenticode evidence for your assembly when it creates the hosting AppDomain, but what evidence does it have?
The AppDomain hosting the control will have three pieces of evidence:
Remember, this only applies to the AppDomain which holds the assembly; the assembly itself will have all the evidence that you would expect. That leads back to the point of the original post which was that your assembly may be granted higher permissions than the AppDomain it’s sandboxed within. In order to get around this you either have to Assert at the assembly’s entry points, or use policy that grants both the assembly and AppDomain the same permission set. (Hmm … another reason why that simple sandboxing model is nicer than the legacy sandbox model?)