|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
CASPOL - StrongName trusts not being applieda C# library which is embedded in an HTML document (loaded as an ActiveX object in Internet Explorer). I first tried a URL condition (http://hostname/*). This worked fine for us, with the downside being that we are deploying this to multiple locations, so we would need to be aware of the URL for each (which will not be known until actual deployment to our client takes place). I think a better solution would be to using the strong name condition. I have signed the assembly and added a code group with the Public Key with Full Trust. However, it seems like the assembly is not actually being recognized as part of the code group, as I almost immediately get errors about permission requests failing. I was first doing this through the caspol command line and assumed I was making a mistake. So on a development machine I used the actual .NET Framework 2.0 Configuration tool. I selected "Import" when asked to specify the public key to make sure I had the correct key. Again, no effect. If I change it to be a URL condition, suddenly everything works. Any thoughts? -- Adam Clauss Are you adding the strong name code group under the appropriate zone code
group (e.g.: LocalIntranet_Zone code group if your code is being loaded from an intranet site)? If so, could you please provide the exact caspol command you are attempting to execute? Show quoteHide quote "Adam Clauss" <cabadam@no.spam.gmail.com> wrote in message news:%23xHgMnH6GHA.2288@TK2MSFTNGP05.phx.gbl... > OK, I have gotten a bit more familiar with using caspol. I am working > with a C# library which is embedded in an HTML document (loaded as an > ActiveX object in Internet Explorer). > > I first tried a URL condition (http://hostname/*). This worked fine for > us, with the downside being that we are deploying this to multiple > locations, so we would need to be aware of the URL for each (which will > not be known until actual deployment to our client takes place). > > I think a better solution would be to using the strong name condition. I > have signed the assembly and added a code group with the Public Key with > Full Trust. However, it seems like the assembly is not actually being > recognized as part of the code group, as I almost immediately get errors > about permission requests failing. > > I was first doing this through the caspol command line and assumed I was > making a mistake. So on a development machine I used the actual .NET > Framework 2.0 Configuration tool. I selected "Import" when asked to > specify the public key to make sure I had the correct key. Again, no > effect. > > If I change it to be a URL condition, suddenly everything works. > > Any thoughts? > > > -- > Adam Clauss > I have tried adding the strong name group to several different groups,
includnig All_Code and LocalIntranet_Zone. The host I am currently testing with is in the Local Intranet zone. This is the command line I used in my latest try: caspol -pp off -machine -ag LocalIntranet_Zone -strong -hex 0x0024000004800000940000000602000000240000525341310004000001000100EF075354B84D12097518119C71A4282A85CA9C64335962CB651EE426BCE21317E92FA247C02646ECF0C939067EA2A45CD17CDE06D318DCD0E39414A8EDEDC3570C3282FBA14D9DBD0B3871FEFACE61F1D5F74F4A780AF5FB9E3E2539574E3D95E7542F65D7DB4A50C78C0AE20C9057F144755F0A7CDE7A4AD5E734C6E902B7CB -noname -noversion FullTrust -name SGOperatorMap_SN I can then confirm that the new group was indeed added with FullTrust under LocalIntranet (my group 1.2 - this group was added as 1.2.3) by running: caspol -lg I'm sure that will wrap and look quite lovely... -- Show quoteHide quoteAdam Clauss "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:9E852A65-0FE5-43E6-9E54-1554EA65A056@microsoft.com... > Are you adding the strong name code group under the appropriate zone code > group (e.g.: LocalIntranet_Zone code group if your code is being loaded > from an intranet site)? If so, could you please provide the exact caspol > command you are attempting to execute? > > > "Adam Clauss" <cabadam@no.spam.gmail.com> wrote in message > news:%23xHgMnH6GHA.2288@TK2MSFTNGP05.phx.gbl... >> OK, I have gotten a bit more familiar with using caspol. I am working >> with a C# library which is embedded in an HTML document (loaded as an >> ActiveX object in Internet Explorer). >> >> I first tried a URL condition (http://hostname/*). This worked fine for >> us, with the downside being that we are deploying this to multiple >> locations, so we would need to be aware of the URL for each (which will >> not be known until actual deployment to our client takes place). >> >> I think a better solution would be to using the strong name condition. I >> have signed the assembly and added a code group with the Public Key with >> Full Trust. However, it seems like the assembly is not actually being >> recognized as part of the code group, as I almost immediately get errors >> about permission requests failing. >> >> I was first doing this through the caspol command line and assumed I was >> making a mistake. So on a development machine I used the actual .NET >> Framework 2.0 Configuration tool. I selected "Import" when asked to >> specify the public key to make sure I had the correct key. Again, no >> effect. >> >> If I change it to be a URL condition, suddenly everything works. >> >> Any thoughts? >> >> >> -- >> Adam Clauss >> > Sorry, I didn't quite catch on that this is for an IE-hosted control last
time I read your initial post in this thread. Your strong name membership code group is probably fine. Instead, you're very likely running in an issue caused by the way the IE host exposes evidence for a control assembly. For an explanation of this behaviour and the available workarounds, see http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx. Show quoteHide quote "Adam Clauss" <caba***@tamu.edu> wrote in message news:12iqoe44o2kji1f@corp.supernews.com... >I have tried adding the strong name group to several different groups, >includnig All_Code and LocalIntranet_Zone. > > The host I am currently testing with is in the Local Intranet zone. This > is the command line I used in my latest try: > caspol -pp off -machine -ag LocalIntranet_Zone -strong -hex > 0x0024000004800000940000000602000000240000525341310004000001000100EF075354B84D12097518119C71A4282A85CA9C64335962CB651EE426BCE21317E92FA247C02646ECF0C939067EA2A45CD17CDE06D318DCD0E39414A8EDEDC3570C3282FBA14D9DBD0B3871FEFACE61F1D5F74F4A780AF5FB9E3E2539574E3D95E7542F65D7DB4A50C78C0AE20C9057F144755F0A7CDE7A4AD5E734C6E902B7CB > -noname -noversion FullTrust -name SGOperatorMap_SN > > I can then confirm that the new group was indeed added with FullTrust > under LocalIntranet (my group 1.2 - this group was added as 1.2.3) by > running: > caspol -lg > > I'm sure that will wrap and look quite lovely... > > -- > Adam Clauss > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:9E852A65-0FE5-43E6-9E54-1554EA65A056@microsoft.com... >> Are you adding the strong name code group under the appropriate zone code >> group (e.g.: LocalIntranet_Zone code group if your code is being loaded >> from an intranet site)? If so, could you please provide the exact caspol >> command you are attempting to execute? >> >> >> "Adam Clauss" <cabadam@no.spam.gmail.com> wrote in message >> news:%23xHgMnH6GHA.2288@TK2MSFTNGP05.phx.gbl... >>> OK, I have gotten a bit more familiar with using caspol. I am working >>> with a C# library which is embedded in an HTML document (loaded as an >>> ActiveX object in Internet Explorer). >>> >>> I first tried a URL condition (http://hostname/*). This worked fine for >>> us, with the downside being that we are deploying this to multiple >>> locations, so we would need to be aware of the URL for each (which will >>> not be known until actual deployment to our client takes place). >>> >>> I think a better solution would be to using the strong name condition. >>> I have signed the assembly and added a code group with the Public Key >>> with Full Trust. However, it seems like the assembly is not actually >>> being recognized as part of the code group, as I almost immediately get >>> errors about permission requests failing. >>> >>> I was first doing this through the caspol command line and assumed I was >>> making a mistake. So on a development machine I used the actual .NET >>> Framework 2.0 Configuration tool. I selected "Import" when asked to >>> specify the public key to make sure I had the correct key. Again, no >>> effect. >>> >>> If I change it to be a URL condition, suddenly everything works. >>> >>> Any thoughts? >>> >>> >>> -- >>> Adam Clauss >>> >> > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message So... that rather makes using the code security a lot less useful. I mean, news:6D38D89F-7F11-447E-8097-BF267536B0AF@microsoft.com... > Sorry, I didn't quite catch on that this is for an IE-hosted control last > time I read your initial post in this thread. Your strong name membership > code group is probably fine. Instead, you're very likely running in an > issue caused by the way the IE host exposes evidence for a control > assembly. For an explanation of this behaviour and the available > workarounds, see > http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx. it seems if you are going to bother blocknig thigns from 'remote' sites, and allow for special cases within that, this would definately be something you would want to do. -- Adam Clauss Have you tried the assertion workaround? If so, is there some aspect of its
use that makes it impractical for your scenario? Show quoteHide quote "Adam Clauss" <caba***@tamu.edu> wrote in message news:12j7a74nqnu4b7@corp.supernews.com... > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:6D38D89F-7F11-447E-8097-BF267536B0AF@microsoft.com... >> Sorry, I didn't quite catch on that this is for an IE-hosted control last >> time I read your initial post in this thread. Your strong name >> membership code group is probably fine. Instead, you're very likely >> running in an issue caused by the way the IE host exposes evidence for a >> control assembly. For an explanation of this behaviour and the available >> workarounds, see >> http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx. > > > So... that rather makes using the code security a lot less useful. I > mean, it seems if you are going to bother blocknig thigns from 'remote' > sites, and allow for special cases within that, this would definately be > something you would want to do. > > -- > Adam Clauss > Asserting will not work will it?
He states in one of his comments: "You're correct, Asserting a permission requires that you be granted the permission in the first place. This post is mostly about getting the control to not throw once it has already been granted permissions." But in the blog itself he says that assemblies will not match a strong name condition when loaded in IE. Therefore, it will not match the FullTrust group I setup. How would placing Asserts affect anything? -- Show quoteHide quoteAdam Clauss "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:%23lvJuz58GHA.1256@TK2MSFTNGP04.phx.gbl... > Have you tried the assertion workaround? If so, is there some aspect of > its use that makes it impractical for your scenario? > > > "Adam Clauss" <caba***@tamu.edu> wrote in message > news:12j7a74nqnu4b7@corp.supernews.com... >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message >> news:6D38D89F-7F11-447E-8097-BF267536B0AF@microsoft.com... >>> Sorry, I didn't quite catch on that this is for an IE-hosted control >>> last time I read your initial post in this thread. Your strong name >>> membership code group is probably fine. Instead, you're very likely >>> running in an issue caused by the way the IE host exposes evidence for a >>> control assembly. For an explanation of this behaviour and the >>> available workarounds, see >>> http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx. >> >> >> So... that rather makes using the code security a lot less useful. I >> mean, it seems if you are going to bother blocknig thigns from 'remote' >> sites, and allow for special cases within that, this would definately be >> something you would want to do. >> >> -- >> Adam Clauss >> > > If your assembly has SecurityPermission\Assertion permission as well as the
permission being demanded (as evaluated under the CAS policy settings only), the assertion will prevent the call stack walk from reaching the app domain boundary, so the lesser permission set assigned at the app domain level will be irrelevant. If you need to convince yourself that this works, why not just go ahead and try it? Show quoteHide quote "Adam Clauss" <caba***@tamu.edu> wrote in message news:12jpim1rrn3idef@corp.supernews.com... > Asserting will not work will it? > > He states in one of his comments: > "You're correct, Asserting a permission requires that you be granted the > permission in the first place. This post is mostly about getting the > control to not throw once it has already been granted permissions." > > But in the blog itself he says that assemblies will not match a strong > name condition when loaded in IE. Therefore, it will not match the > FullTrust group I setup. How would placing Asserts affect anything? > > -- > Adam Clauss > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:%23lvJuz58GHA.1256@TK2MSFTNGP04.phx.gbl... >> Have you tried the assertion workaround? If so, is there some aspect of >> its use that makes it impractical for your scenario? >> >> >> "Adam Clauss" <caba***@tamu.edu> wrote in message >> news:12j7a74nqnu4b7@corp.supernews.com... >>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in >>> message news:6D38D89F-7F11-447E-8097-BF267536B0AF@microsoft.com... >>>> Sorry, I didn't quite catch on that this is for an IE-hosted control >>>> last time I read your initial post in this thread. Your strong name >>>> membership code group is probably fine. Instead, you're very likely >>>> running in an issue caused by the way the IE host exposes evidence for >>>> a control assembly. For an explanation of this behaviour and the >>>> available workarounds, see >>>> http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx. >>> >>> >>> So... that rather makes using the code security a lot less useful. I >>> mean, it seems if you are going to bother blocknig thigns from 'remote' >>> sites, and allow for special cases within that, this would definately be >>> something you would want to do. >>> >>> -- >>> Adam Clauss >>> >> >> > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message I'm in the process of doing so, but there are a lot of 'entry' points to news:95044A7F-0508-4096-A3B6-017BA604AEAF@microsoft.com... > If your assembly has SecurityPermission\Assertion permission as well as > the permission being demanded (as evaluated under the CAS policy settings > only), the assertion will prevent the call stack walk from reaching the > app domain boundary, so the lesser permission set assigned at the app > domain level will be irrelevant. If you need to convince yourself that > this works, why not just go ahead and try it? nail down. So maybe I am misunderstanding the goal of the assert and what the problem is. So, initially, the AppDomain is loaded, and as it in itself has no strong name, we get the LocalIntranet zone permissions. Our assembly is then loaded into the AppDomain, with the same permission set. However, by putting an Assert in there, the CLR (I assume this is where the security check is done?) will recognize that this particular assembly actually matches the Strong Name condition, and allow it to perform the actions? -- Adam Clauss 
Other interesting topics
TripleDES output size
Problem with pkcs #7 strong name validation failed problem Trusting a location for Framework 2.x how to use microsoft application blocks ent lib june 2005 Windows File Encryption Re: Encrypting using RSA private Key Getting SignXML to Emit Namespace-Qualified XML Can't copy encrypted files to the network Single sign on for Outlook Web Access. |
|||||||||||||||||||||||
