 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Security / February 2006StrongNameIdentityPermission problem
Hello, I have the following situation: Assembly A.dll have some routine inside that application B.exe uses. I waht to prevent other people from loading A.dll and call the method with the routine. For that, I make A.dll and B.dll strong named, and the method "String SensitiveRoutine()" have the StrongNameIdentityPermission attribute with the pulic key of B.exe, I set the security action to Demand. and I receive this secutiry error: Request for the permission of type System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed. If I set the security action to LinkDemand I don't receive the error, but other application C.exe with different public key can call the method! and I don't want this. If I put the attribute at assembly level [assembly:StrongNameIdentityPermissionAttribute........] with RequestMinimum as security action, it does't work. what should I do to ensure that the code that call the sensitive routine is one from the strong named assemblies that I signed before? thanks > Hello, > I have the following situation: [quoted text clipped - 13 lines] > Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 > failed. This is to be expected in most cases since their is often some .NET Framework code (which is not signed with your strong naming key) on the call stack. Link demands are usually used for identity permission demands to prevent exactly this issue. > If I set the security action to LinkDemand I don't receive the error, but > other application C.exe with different public key can call the method! This is not expected behaviour under version 1.1 of the .NET Framework. Are you calling SensitiveRoutine directly from C.exe, or is the call being made by invoking a method in A.dll or B.dll that then invokes SensitiveRoutine? > If I put the attribute at assembly level > [assembly:StrongNameIdentityPermissionAttribute........] with > RequestMinimum > as security action, it does't work. Assembly-level permission attributes affect only the assembly in which they appear. They have no impact whatsoever on demands placed on callers from other assemblies, so the behaviour you describe is to be expected. > what should I do to ensure that the code that call the sensitive routine > is > one from the strong named assemblies that I signed before? That depends by what you mean by "ensure". Highly privileged code can bypass any identity permission even under v. 1.1. In v. 2.0, fully trusted code will automatically pass all identity permission demands, so your SNIP attribute will provide even less protection there. If you want to more effectively screen callers, a licensing scheme may be more effective. However, this wouldn't offer substantial protection against a determined and highly privileged attacker, so it may or may not be worth the trouble of implementing in your particular case. This is not expected behaviour under version 1.1 of the .NET Framework. Are you calling SensitiveRoutine directly from C.exe, or is the call being made by invoking a method in A.dll or B.dll that then invokes SensitiveRoutine? [ED] Yes, I called the sensitive routine directly from the .exe(s) > If I put the attribute at assembly level > [assembly:StrongNameIdentityPermissionAttribute........] with > RequestMinimum > as security action, it does't work. Assembly-level permission attributes affect only the assembly in which they appear. They have no impact whatsoever on demands placed on callers from other assemblies, so the behaviour you describe is to be expected. [ED] Thanks for this comment! > what should I do to ensure that the code that call the sensitive routine > is > one from the strong named assemblies that I signed before? That depends by what you mean by "ensure". Highly privileged code can bypass any identity permission even under v. 1.1. In v. 2.0, fully trusted code will automatically pass all identity permission demands, so your SNIP attribute will provide even less protection there. If you want to more effectively screen callers, a licensing scheme may be more effective. However, this wouldn't offer substantial protection against a determined and highly privileged attacker, so it may or may not be worth the trouble of implementing in your particular case. [ED] I need that my routine ONLY be called from a strong named assembly signed with my key, no one other can do it. Thanks for your comments again :) > This is not expected behaviour under version 1.1 of the .NET Framework. > Are [quoted text clipped - 4 lines] > [ED] > Yes, I called the sensitive routine directly from the .exe(s) Are you absolutely certain that C.exe is signed with a different key? If so, could you please post the exact code used for your SNIP attribute? > [ED] > I need that my routine ONLY be called from a strong named assembly signed > with my key, no one other can do it. It simply isn't possible to completely prevent calls into your method by undesired callers. Highly privileged code run by a highly privileged attacker will always be able to bypass whatever protection you add. Might you be able to share a bit more detail about how your application is deployed and who you are attempting to protect against? > It simply isn't possible to completely prevent calls into your method by > undesired callers. Highly privileged code run by a highly privileged > attacker will always be able to bypass whatever protection you add. Might > you be able to share a bit more detail about how your application is > deployed and who you are attempting to protect against? [ED] Well, my application is a windows service acting as a server for many clients, and I have other .exe for activate an aplication. This .exe will ask the user for the serial and activation number, and the validation and activation process will take place in a common assembly. When I said common I mean that the activator, the service, and other applications I have will use it. All those assemblies (the activator and the service) are signed with my key. As you can see, if some one creates another app that uses my assembly, can call the methods that activate the application, because they're public to enable the .exe and the service to activate it and check the activation respectively. I thought will be possible to protect the calls to the activation methods inside the .dll using the SNIP attribute. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.