Re: HTML embbeded (via <object> tag) Strong FullTrust Assemblies f

From: Greg Stangler (
Date: 02/07/05

Date: Mon, 7 Feb 2005 05:07:02 -0800

Your answer has been very helpful.
It makes sense to me that the AppDomain (sandbox) IE is running in has
limited trust, and so my loaded (embedded) assembly's permissions are reduced
to the appdomain's permissions (i.e. lowered from fulltrust status).
However, I am unclear on how to tell IE about a 'site membership condition'
and apply it to the client in a way that the next time IE runs, it's
appdomain will now allow my assembly full access. As a matter of fact, I'm
not even sure if 'sitemembershipcondition' is an attribute within CAS Policy
or IE.
I'm hoping you can take another minute to help claify, or point me to some
additional documentation.
One other question:
Can an assembly with internet permissions running as an embedded object,
create a new AppDomain, and assign more liberal (e.g. fulltrust) permissions
to the new domain, then load and run an assembly into the new full trust
Domain and have it run with the the new, more liberal permissions? i.e. Can
a assembly in one AppDomain create a new AppDomain, and give it more liberal
permissions that it had for itself?
FYI: my goal in life (well ... maybe just this particular project), is to
enable a fully trusted assembly to run as an embedded object within an IE
browser via a web page, without requiring the user to change security
settings on their browser.
Thanks again for your patience and time with a .NET security newbee,

"Nicole Calinoiu" wrote:

> See for a
> description of the problem and possible solutions.
> "Greg Stangler" <Greg> wrote in message
> > My problem:
> > I am attempting to create a strong named .NET library assembly which needs
> > FullTrust permissions when loaded from the Internet zone and can be
> > embedded
> > (via the <object> tag ) within an HTML browser page.
> >
> > e.g.
> > .
> > <object id="checkStrongNameAccess" height={controlHeight}
> > width={controlWidth}
> > classid="http:MyFullTrustAssembly.exe#MyUserControlNameSpace.MyUserControlClass"
> > </object>
> > .
> >
> > Note: I've tried the 'MyFullTrustAssembly' assemblies as both exe, and
> > dll.
> >
> > The problem is when this assembly is given a strong name, and a code group
> > with the same strong name has been created via the caspol utility, it no
> > longer activates when the html page is activated. However, when the same
> > strong named assembly is accessed as an application (via an <HREF. .exe>),
> > the assembly runs with full trust, but now is no longer embedded.
> >
> > I need this assembly to function within the browser so that it exits when
> > the browser exits.
> >
> > I have also tried adding the assembly individually, and not as a code
> > group,
> > with the same results.
> >
> > I can make this work, if I set the 'Trusted Sites' zone to FullTrust
> > permissions (via caspol), and then add the necessary internet site to the
> > IE
> > Browsers list of trusted sites. In this configuration, the assembly is
> > now
> > allowed FullTrust as an embedded (<object./>) component.
> >
> > I do not want to force customers to add a web site to their trusted sites
> > list since this creates a security hole.
> > I do not want to modify the clients IE configuration in any way if at all
> > possible.
> > I want to be able to apply a strong name to my internet delivered
> > assemblies
> > and load from the internet zone either via a strong named code group, or
> > via
> > individual assembly groups.
> >
> > My question(s):
> > Is the configuration I am attempting outside of security policy bounds
> > supported by Microsoft ? It shouldn't be, since setting trust at the
> > site
> > level does work.
> >
> > If it is not outside of security policy limits, how do I configure the
> > local
> > CAS policies (via caspol) on a strong named 'FullTrust' assembly, so that
> > the
> > assembly can be used as an embedded object within html, and still have
> > unlimited access the all of the clients local resources?
> >
> > Cordially
> > Greg Stangler
> >

Relevant Pages

  • Re: Reason behind implicit FullTrust LinkDemand?
    ... The removal of permissions from the Internet Zone or the ... time to protect the System* assemblies from this attack. ... the security holes are patched. ... The knew the LinkDemand would be a fix. ...
  • Re: security/strong name/zones clarification needed
    ... Was this also true in the Intranet Zone? ... >child code-group with full permissions granted to any ... >> needs to host the CLR, it creates an AppDomain, but due ... All my assemblies are strong named. ...
  • Re: security/strong name/zones clarification needed
    ... > this AppDomain needs to be setup before your assembly can be loaded, ... > Your assembly will have enough permissions, ... When the call stack is initiated, ... All my assemblies are strong named. ...
  • Re: Okay.. what is going on here .. Security error?
    ... and changed the local intranet permissions setting - ... > against the security policy, and a permission grant is generated. ... > there is a more restrictive policy placed on LocalIntranet assemblies. ...
  • Re: security/strong name/zones clarification needed
    ... several but not publicly documented) about child code-group permissions ... a strong-name, or Authenticode signature evidence. ... This problem would also crop up in the AppDomain case also. ... All my assemblies are strong named. ...