Re: Confusion about .Net AllowPartiallyTrustedCallers (IE).

"Apu Nahasapeemapetilon" <ApuNahasapeemapetilon@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote

Hi Apu. See comments inline.

[...]The UserControl assembly is signed, put into the GAC and registered
for
access by COM clients (like IE). The web page that contains the
UserContorl
is part of web site that's located on the "Local Intranet Zone".

To get around the security exceptions that occur;

First I tried using mscorcfg.msc to "Adjust Security Zone" -> "Make
changes
to this computer" -> "Local Intranet" -> "Full Trust". This procedure
worked
okay, but my end users probably won't want to make the global change for
the
entire "Local Intranet". So I reset the "Local Intranet" back to the
"Default
Level".

One of the main goals when Microsoft designed the CLR was to avoid luring
attacks. The assumption is that strong named assemblies will often have more
trust then unsigned assemblies because the strong name is a "strong
evidence". If this assembly will be called by another assembly that for
instance does not have a strong name this could be a luring attack: "Someone
with less permissions cannot perform a task and calls someone else that has
more permissions to perform this task.

A solution that is obvious would be to always compare the permissions of
both assemblies. This has a huge performance impact so the designers made
the following decision: If an assembly has a strong name the caller must
have Full Trust. If the caller does not have full trust the call will be
rejected. This solves the problem of a luring attack in this scenario.

But in practice this means a lot of applications will simply not work. So
they used another "trick". A developer can switch off this behavior by
annotating his assembly with the attribute AllowPartiallyTrustedCallers.

The "Design Pattern" is delegation of responsibility: "If you as a developer
use this attribute, your code could be a target for a luring attack and it's
up to you to do a "strong" code review so that you can guarantee that this
will not happen.

That's why it worked when you set the trust level to "Full Trust".


Second I used mscorcfg.msc to create a new "Code Group" for my UserControl
as: "Create a new code group" -> "Strong Name" -> "Import" (select my
UserControl DLL) -> "Full Trust". This procedure didn't work. The security
exceptions kept occurring. So I deleted this new code group. I'm wondering
if
anyone had any ideas why this process didn't work. Should it have worked?


No, because the caller of your assembly, which is IE, does not have full
trust. By default your Web page runs in an Internet Explorer zone. This is
either "local intranet" or "internet". By default these zones are mapped to
the permission sets LocalInranet_Zone or Internet_Zone by the CLR security
system. So the caller does not have full trust and the result is a security
exception because the user control assembly is not marked with the attribute
AllowPartiallyTrustedCallers.


Third I modified the UserControl source code. I preceded the security
exception causing code with the appropriate new security permission
(PermissionState.Unrestricted).Assert() and followed security exception
causing code with the appropriate security permission.RevertAll(); This
procedure worked okay. Is this procedure working due to both the Assert -
RevertAll + the fact that the assembly is in the GAC?


In .NET 2.0 an assembly that is in the GAC has Full Trust always. This is
the reason why an assert for full trust works. But this is very dangerous
because full trust really means full trust. So you should not use this
pattern here. Instead mark your assembly with AllowPartiallyTrustedCallers
and review your code carefully.



(Yes, yes for all the experts: a custom permission and demand/assert would
be the best solution ;-)





Hope that helps

Michael

[MVP Security]

http://staff.newtelligence.net/michaelw


.

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. ...
    (microsoft.public.dotnet.security)
  • Re: Domain was in the wrong state to perform the security operation
    ... You may need to change the security ... option for "let everyone permissions apply to anonymous users" to ENABLED. ... > other being sure that the W2003 domain controllers are also wins clients so that ... > experienced Active Directory people over there that know a lot about trust issues. ...
    (microsoft.public.win2000.security)
  • 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. ...
    (microsoft.public.dotnet.security)
  • Re: CAS & GAC: connection?
    ... > assemblies will have full trust, and most assemblies in the GAC are ... > installed, so in most cases, assemblies in the GAC will be fully trusted. ... >> It can request fewer permissions, but it will get Full Trust. ...
    (microsoft.public.dotnet.security)
  • Re: .net security vs. windows security
    ... granted the permissions associated with that code-group. ... assemblies being digitally signed with the private ... certificates can figure quite prominently into CAS infrastructure. ... >> Generally speaking Code Access Security, ...
    (microsoft.public.dotnet.security)
Loading