Re: security/strong name/zones clarification needed
From: Peter Singer (petes@knorrassociates.com)
Date: 02/05/03
- Next message: David Spectorman: "Key store"
- Previous message: Peter Singer: "Re: security/strong name/zones clarification needed"
- In reply to: Crirus: "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: Wed, 5 Feb 2003 05:10:14 -0800
Adding my site to a trusted sites zone or granting Full
Trust to my URL is not a secure way of doing this. Things
can get spoofed. I want it to work via my Strong Name,
which it doesn't seem to want to.
>-----Original Message-----
>Try to add your site to trust sites zone and set
permission there to full
>trust to se if it work.
>My tests worked just fine.
>
>
>
>"Peter Singer" <petes@knorrassociates.com> wrote in
message
>news:075e01c2cc51$28f3aa70$d5f82ecf@TK2MSFTNGXA12...
>> I tried it with all ActiveX settings set to enabled.
Still
>> no luck. I don't have the problem when using a WinForm
>> app. To clarify, here's the scenario:
>>
>> I have a strongly signed managed control (it simply has
a
>> button on it). If I house it in a WinForm app and
>> configure Full Trust to anything with my Strong Name and
>> plop it on a vroot, I can do
http://webserver/winapp.exe.
>> However, if I house the managed control in an HTML page
>> via an OBJECT tag and try
>> http://webserver/HousingPage.html it doesn't work even
>> though I told the .net Framework Config tool to accept
>> anything with my strong name in it.
>>
>> I tried asserting a fulltrust permission set in the
>> constructor (see code below) of the managed control but
>> still don't get anything except the square, triangle and
>> circle. The only way I can seem to get this control to
>> work w/in IE is if I grant full trust to the particular
>> URL (e.g. http://localhost/*). What am I missing here?
>>
>>
>> >-----Original Message-----
>> >Peter,
>> >
>> > I'm not familiar with doing this to custom
controls,
>> I've only ever done
>> >this with WinForm apps being downloaded. In this
>> instance, I add the assert
>> >to the Main() method. If there are any initialization
>> methods for a
>> >control, you may have to override them and do the
assert
>> there. Also, have
>> >you looked at Cirirus' post? Does this zone have
>> permission to use custom
>> >controls?
>> >
>> >--
>> >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:077401c2cb90$19929080$d2f82ecf@TK2MSFTNGXA09...
>> >> Shawn,
>> >>
>> >> I'm still missing something. I've got a simple user
>> >> control with one button on it. There's only one
method,
>> >> namely New(), in the entire app. I've got the
following
>> >> code in there:
>> >>
>> >> Dim zz As New System.Security.PermissionSet
>> >> (System.Security.Permissions.PermissionState.None)
>> >> Dim KAIpk As Byte() = {the csv byte string}
>> >> Dim KAIpkblob As New
>> >> System.Security.Permissions.StrongNamePublicKeyBlob
>> (KAIpk)
>> >> Dim xx As New
>> >>
System.Security.Permissions.StrongNameIdentityPermission
>> >> (KAIpkblob, Nothing, Nothing)
>> >> zz.AddPermission(xx)
>> >> zz.Assert()
>> >>
>> >> It still doesn't let me see the control in IE. What
am I
>> >> missing?
>> >>
>> >> Thanks,
>> >> Peter
>> >>
>> >>
>> >>
>> >> >-----Original Message-----
>> >> >The Assert needs to go in the method of your control
>> that
>> >> is at the top of
>> >> >the callstack. So, everywhere that code flow enters
>> your
>> >> control, those
>> >> >methods should get the asserts.
>> >> >
>> >> >--
>> >> >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:06dc01c2c963$40d177d0$89f82ecf@TK2MSFTNGXA01...
>> >> >> Shawn,
>> >> >>
>> >> >> Thanks. I'm a bit confused. So I've got my dll
that's
>> >> >> embedded in an OBJECT tag. Does the Assert code
go in
>> >> its
>> >> >> constructor?
>> >> >>
>> >> >> I'm not clear on what the code needs to look
like. I
>> >> tried:
>> >> >>
>> >> >> Dim zz As New System.Security.PermissionSet
>> >> >> (System.Security.Permissions.PermissionState.None)
>> >> >>
>> >> >> Dim KAIpk As Byte() = {a bunch of csv numbers}
>> >> >> Dim KAIpkblob As New
>> >> >>
System.Security.Permissions.StrongNamePublicKeyBlob
>> >> (KAIpk)
>> >> >> Dim xx As New
>> >> >>
>> System.Security.Permissions.StrongNameIdentityPermission
>> >> >> (KAIpkblob, Nothing, Nothing)
>> >> >>
>> >> >> zz.AddPermission(xx)
>> >> >> zz.Assert()
>> >> >>
>> >> >> And I've tried:
>> >> >>
>> >> >> Dim zz As New System.Security.PermissionSet
>> >> >>
>> >>
>>
(System.Security.Permissions.PermissionState.Unrestricted)
>> >> >> zz.Assert()
>> >> >>
>> >> >> neither of which worked. Can you clarify please?
>> >> >>
>> >> >> Peter
>> >> >>
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >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: David Spectorman: "Key store"
- Previous message: Peter Singer: "Re: security/strong name/zones clarification needed"
- In reply to: Crirus: "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
|
