Re: security/strong name/zones clarification needed
From: Peter Singer (petes@knorrassociates.com)
Date: 02/04/03
- Next message: Greg Dunn: "Re: SLAMMER WORM for SQLSERVER2K"
- Previous message: Philip Nunn [MSFT]: "Re: WMI -> WinXP (multi-user, @ workgroup, not in domain)"
- In reply to: Michel Gallant (MVP): "Re: security/strong name/zones clarification needed"
- Next in thread: Peter Singer: "Re: security/strong name/zones clarification needed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Peter Singer" <petes@knorrassociates.com> Date: Tue, 4 Feb 2003 10:00:26 -0800
Was this also true in the Intranet Zone? Did this happen
using auto-deploy or a user control w/in IE?
>-----Original Message-----
>Also, note that in .net Framework 1.0, there was a bug
(reported by
>several but not publicly documented) about child code-
group permissions
>and the Internet zone.
>I was trying to deploy assemblies directly as URLs, and
had a custom
>child code-group with full permissions granted to any
code with either
>a strong-name, or Authenticode signature evidence. This
fails due to a bug in
>how .net Framework 1.0 uses the combined info. of the
code groups.
>This problem would also crop up in the AppDomain case
also.
>Apparently the problem has been fixed in .net 1.1?
>
> - Michel Gallant
> MVP Security
> JavaScience Consulting
> http://pages.istar.ca/~neutron
>
>"Shawn Farkas [MS]" wrote:
>
>> Hi Peter,
>>
>> You're running into an interesting scenario.
When assemblies are
>> executed in a web page, they are hosted by IE. When IE
realizes it
>> needs to host the CLR, it creates an AppDomain, but due
to the fact that
>> this AppDomain needs to be setup before your assembly
can be loaded, only
>> minimal evidence can be supplied to it. So in this
instance, only the fact
>> that it is on the Internet zone and its URL can be
supplied. Any evidence
>> specific to the assembly being loaded, such as the
publisher's certificate
>> or a strong name cannot be given to the assembly, as it
is not loaded yet.
>> Once the AppDomain is setup, the assembly is loaded
into it. At this
>> point, the CLR sees all the evidence that applies to
the assembly, but it is
>> too late to apply this evidence to the AppDomain. So
your assembly itself
>> will recieve the permission grant you expect (in this
case, FullTrust). So
>> far, so good.
>> Now your assembly is executing with the FullTrust
permission set. But
>> it is going to make an API call. A permission check is
now started.
>> Your assembly will have enough permissions, but the
code access security
>> engine works with a call-stack walk, meaning that every
method and AppDomain
>> on the current call stack must have enough permission
to call the requested
>> API. When the call stack is initiated, it hits the
AppDomain boundary
>> within the IE host that did not get given your strong
name signature as
>> evidence. This means that this AppDomain boundary will
only resolve to
>> Internet permissions. And so the SecurityException is
thrown.
>> The work around for this is simple. Stack walks
can be prevented by
>> asserting permissions. Any time a stack walk
encounters a stack frame where
>> a set of permissions have been asserted, the walk
returns successfully,
>> without proceeding any further. So the easiest thing
to do would be to
>> create a permission set in your entry point methods
that consists of all the
>> permissions you need, and call the .Assert() method of
that permission set.
>>
>> -Shawn
>> --
>> This posting is provided "AS IS" with no warranties,
and confers no rights.
>> Please do not send email directly to this alias, this
alias is for newsgroup
>> purposes only.
>>
>> "Peter Singer" <petes@knorrassociates.com> wrote in
message
>> news:06df01c2c7b9$5b8d9dc0$8df82ecf@TK2MSFTNGXA02...
>> > I have a win app that I've posted on an intranet web
>> > server. All my assemblies are strong named. I've went
in
>> > to the .net security configuration tool and granted
>> > anything with my strong name full trust. All other
>> > settings (including intranet) are at their defaults.
>> >
>> > I can do http://localhost/myapp.exe and it works fine.
>> > However, if I access an html page that has an assembly
>> > embedded in an object tag I never get the control to
>> > display (I get the little square w/a square, circle
and
>> > triangle in it). If I grant the Intranet zone full
trust
>> > though, it works.
>> >
>> > I thought doing a http://localhost/myapp.exe runs the
app
>> > inside of the IEEXEC context, which takes on the
security
>> > as if running w/in IE. If that's the case why is
>> > http://localhost/myapp.exe working but
>> > http://localhost/myapp.html (with the embedded object
tag)
>> > not (unless I grant full trust to Intranet)?
>> >
>
>.
>
- Next message: Greg Dunn: "Re: SLAMMER WORM for SQLSERVER2K"
- Previous message: Philip Nunn [MSFT]: "Re: WMI -> WinXP (multi-user, @ workgroup, not in domain)"
- In reply to: Michel Gallant (MVP): "Re: security/strong name/zones clarification needed"
- Next in thread: Peter Singer: "Re: security/strong name/zones clarification needed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
