|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Another StrongNameIdentityPermission/LinkDemand questionI've seen a lot of traffic on the newsgroup about using
StrongNameIdentityPermission with LinkDemand to restrict the direct caller only trusted assemblies, and it seems like this should work. I added the following attributes to a method in a strong named assembly (dll). [StrongNameIdentityPermission( SecurityAction.LinkDemand, PublicKey = "xxx...xxx" ) ] public ResponseData OpenServiceSession( string configName ) To test, I tried calling from an unsigned EXE and it worked just fine. The call was allowed to be made in spite of the LinkDemand. Is there anything I need to specify at the class or assembly level to enable this LinkDemand? Any ideas about debugging this? I guess you are using 2.0 - These checks are only done if you are running
in partial trust. dominick Show quoteHide quote > I've seen a lot of traffic on the newsgroup about using > StrongNameIdentityPermission with LinkDemand to restrict the direct > caller only trusted assemblies, and it seems like this should work. I > added the following attributes to a method in a strong named assembly > (dll). > > [StrongNameIdentityPermission( > SecurityAction.LinkDemand, > PublicKey = "xxx...xxx" ) > ] > public ResponseData OpenServiceSession( string configName ) > To test, I tried calling from an unsigned EXE and it worked just fine. > The call was allowed to be made in spite of the LinkDemand. Is there > anything I need to specify at the class or assembly level to enable > this LinkDemand? Any ideas about debugging this? > I see. I think I was trying to use it for a purpose it was not
intended. I am not so much interested in security as I am licensing. There are certain entry points that I want code we own to have unlimited access to, but disallow access to 3rd party code. I was able to compare GetCallingAssembly().GetName().PublicKey to our public key and achieve my original purpose that way. But it would be nice if you could do that declaratively. Thanks for the reply. Dominick Baier wrote: Show quoteHide quote > I guess you are using 2.0 - These checks are only done if you are running > in partial trust. > > dominick > > > I've seen a lot of traffic on the newsgroup about using > > StrongNameIdentityPermission with LinkDemand to restrict the direct > > caller only trusted assemblies, and it seems like this should work. I > > added the following attributes to a method in a strong named assembly > > (dll). > > > > [StrongNameIdentityPermission( > > SecurityAction.LinkDemand, > > PublicKey = "xxx...xxx" ) > > ] > > public ResponseData OpenServiceSession( string configName ) > > To test, I tried calling from an unsigned EXE and it worked just fine. > > The call was allowed to be made in spite of the LinkDemand. Is there > > anything I need to specify at the class or assembly level to enable > > this LinkDemand? Any ideas about debugging this? > > Hello,
if you put that code on your assembly, one can easily decompile your code, remove the licensing code and recompile it. Licensing removed, and nothing you can do about this. The only option is not to give your code away. The only thing you can do is to raise the bar by using obfuscation - so that the reverse engineering gets more costly than buying your stuff. Best regards, Henning Krause <jacu***@gmail.com> wrote in message Show quoteHide quote news:1154199516.081603.7760@s13g2000cwa.googlegroups.com... >I see. I think I was trying to use it for a purpose it was not > intended. I am not so much interested in security as I am licensing. > There are certain entry points that I want code we own to have > unlimited access to, but disallow access to 3rd party code. > > I was able to compare GetCallingAssembly().GetName().PublicKey to our > public key and achieve my original purpose that way. But it would be > nice if you could do that declaratively. > > Thanks for the reply. > > Dominick Baier wrote: >> I guess you are using 2.0 - These checks are only done if you are running >> in partial trust. >> >> dominick >> >> > I've seen a lot of traffic on the newsgroup about using >> > StrongNameIdentityPermission with LinkDemand to restrict the direct >> > caller only trusted assemblies, and it seems like this should work. I >> > added the following attributes to a method in a strong named assembly >> > (dll). >> > >> > [StrongNameIdentityPermission( >> > SecurityAction.LinkDemand, >> > PublicKey = "xxx...xxx" ) >> > ] >> > public ResponseData OpenServiceSession( string configName ) >> > To test, I tried calling from an unsigned EXE and it worked just fine. >> > The call was allowed to be made in spite of the LinkDemand. Is there >> > anything I need to specify at the class or assembly level to enable >> > this LinkDemand? Any ideas about debugging this? >> > > True, and we may consider obfuscation, but what other options are
there? Since we are using strong named assemblies the user would have to do this to every single binary that we ship with this enterprise application, which will probably be several dozens, plus the additional headache of doing this for every service pack and hotfix. I suppose our installer could even check the public key before allowing a servie pack or hotfix to be applied. Depends on how paranoid you want to be and how determined your customers are. Henning Krause [MVP - Exchange] wrote: Show quoteHide quote > Hello, > > if you put that code on your assembly, one can easily decompile your code, > remove the licensing code and recompile it. Licensing removed, and nothing > you can do about this. The only option is not to give your code away. > > The only thing you can do is to raise the bar by using obfuscation - so that > the reverse engineering gets more costly than buying your stuff. > > Best regards, > Henning Krause > > <jacu***@gmail.com> wrote in message > news:1154199516.081603.7760@s13g2000cwa.googlegroups.com... > >I see. I think I was trying to use it for a purpose it was not > > intended. I am not so much interested in security as I am licensing. > > There are certain entry points that I want code we own to have > > unlimited access to, but disallow access to 3rd party code. > > > > I was able to compare GetCallingAssembly().GetName().PublicKey to our > > public key and achieve my original purpose that way. But it would be > > nice if you could do that declaratively. > > > > Thanks for the reply. > > > > Dominick Baier wrote: > >> I guess you are using 2.0 - These checks are only done if you are running > >> in partial trust. > >> > >> dominick > >> > >> > I've seen a lot of traffic on the newsgroup about using > >> > StrongNameIdentityPermission with LinkDemand to restrict the direct > >> > caller only trusted assemblies, and it seems like this should work. I > >> > added the following attributes to a method in a strong named assembly > >> > (dll). > >> > > >> > [StrongNameIdentityPermission( > >> > SecurityAction.LinkDemand, > >> > PublicKey = "xxx...xxx" ) > >> > ] > >> > public ResponseData OpenServiceSession( string configName ) > >> > To test, I tried calling from an unsigned EXE and it worked just fine. > >> > The call was allowed to be made in spite of the LinkDemand. Is there > >> > anything I need to specify at the class or assembly level to enable > >> > this LinkDemand? Any ideas about debugging this? > >> > > > If you are planning to do this to "keep the honest people honest", it will
serve as a mild deterrent. If you want to provide some real protect against people who are actively trying to steal something from you, it won't be much of a deterrent. However, if someone who is actively trying to steal your code has your binaries, you are pretty limited in general. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- <jacu***@gmail.com> wrote in message news:1154540976.901824.19310@m79g2000cwm.googlegroups.com... > True, and we may consider obfuscation, but what other options are > there? Since we are using strong named assemblies the user would have > to do this to every single binary that we ship with this enterprise > application, which will probably be several dozens, plus the additional > headache of doing this for every service pack and hotfix. I suppose > our installer could even check the public key before allowing a servie > pack or hotfix to be applied. Depends on how paranoid you want to be > and how determined your customers are. > > Henning Krause [MVP - Exchange] wrote: >> Hello, >> >> if you put that code on your assembly, one can easily decompile your >> code, >> remove the licensing code and recompile it. Licensing removed, and >> nothing >> you can do about this. The only option is not to give your code away. >> >> The only thing you can do is to raise the bar by using obfuscation - so >> that >> the reverse engineering gets more costly than buying your stuff. >> >> Best regards, >> Henning Krause >> >> <jacu***@gmail.com> wrote in message >> news:1154199516.081603.7760@s13g2000cwa.googlegroups.com... >> >I see. I think I was trying to use it for a purpose it was not >> > intended. I am not so much interested in security as I am licensing. >> > There are certain entry points that I want code we own to have >> > unlimited access to, but disallow access to 3rd party code. >> > >> > I was able to compare GetCallingAssembly().GetName().PublicKey to our >> > public key and achieve my original purpose that way. But it would be >> > nice if you could do that declaratively. >> > >> > Thanks for the reply. >> > >> > Dominick Baier wrote: >> >> I guess you are using 2.0 - These checks are only done if you are >> >> running >> >> in partial trust. >> >> >> >> dominick >> >> >> >> > I've seen a lot of traffic on the newsgroup about using >> >> > StrongNameIdentityPermission with LinkDemand to restrict the direct >> >> > caller only trusted assemblies, and it seems like this should work. >> >> > I >> >> > added the following attributes to a method in a strong named >> >> > assembly >> >> > (dll). >> >> > >> >> > [StrongNameIdentityPermission( >> >> > SecurityAction.LinkDemand, >> >> > PublicKey = "xxx...xxx" ) >> >> > ] >> >> > public ResponseData OpenServiceSession( string configName ) >> >> > To test, I tried calling from an unsigned EXE and it worked just >> >> > fine. >> >> > The call was allowed to be made in spite of the LinkDemand. Is >> >> > there >> >> > anything I need to specify at the class or assembly level to enable >> >> > this LinkDemand? Any ideas about debugging this? >> >> > >> > >
Digitally sign files from within a web application
how to grant the application the required permission? PGP - recommendations Storing a private key SIMple SSL question ?? Use of Unrestricted flag ??? Authentication method ?? IIS 5.1 security Client Certifcate Info in Web Service Problem authenticating against renamed Active Directory account |
|||||||||||||||||||||||