Home All Groups Group Topic Archive Search About

Another StrongNameIdentityPermission/LinkDemand question

Author
28 Jul 2006 6:03 PM
jacurry
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?

Author
28 Jul 2006 11:25 PM
Dominick Baier
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?
>
Author
29 Jul 2006 6:58 PM
jacurry
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?
> >
Author
29 Jul 2006 8:32 PM
Henning Krause [MVP - Exchange]
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?
>> >
>
Author
2 Aug 2006 5:49 PM
jacurry
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?
> >> >
> >
Author
2 Aug 2006 6:28 PM
Joe Kaplan (MVP - ADSI)
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.

--
Joe 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
Show quoteHide quote
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?
>> >> >
>> >
>