HTML embbeded (via <object> tag) Strong FullTrust Assemblies fail!

[Greg Stangler]

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" VIEWASTEXT>
</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

 

[Nicole Calinoiu]

See http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx for a
description of the problem and possible solutions.

 

[Peng Jie]

I'm not sure what's the problem with your config.
I created a a winform control with strong name. And it works well with the
<object> tag and internet zone.
I only config the permission of that strong name to fulltrust with
'Microsoft .NET Framework 1.1 Configuration'.
Hope this helps.

 

[Greg Stangler]

Nicole,
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]

Nicole,
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.

You don't "tell IE about" it. Instead, you add a new code group under the
..NET security policy in the same manner that you added the code group that
used your strong name for its membership condition. The new group would use
the assembly's source site as its membership condition instead of the strong
name.

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?

It depends on the exact permission set granted to the first assembly. If by
"internet permissions" you mean the default Internet permission set declared
by the .NET Framework and granted to the Internet_Zone code group, then no,
this wouldn't be possible.

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.

You seem to be mixing up the .NET Framework security policy and the IE
settings here. You will most likely need to alter the client machine's .NET
security policy in order to get your component to be fully trusted in the
first place. Once that's done, you might still need to contend with the
browser's settings, which could very well prevent .NET components from
loading at all. Depending one the client environment, your users may not
even be able to change either one, so you may need to deal with the systems
admins rather than the users in order to get the clients configured
correctly. Of course, if the admins pre-configure stuff, your goal of no

 

[Greg Stangler]

Nicole, thank you for all of your precise help.

I finally got back to this issue this morning, and all worked well. I've
tested several combinations of CAS Policy, and have found one which will suit
our needs well.

cordially, a de-confused CAS policy newbee...