|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Can you verify AppDomain when assemly loads?I was wondering if there any security mechanisms in the framework which
enables me to identify the appdomain which my dll is being loaded into? For ex. if I want to make sure that the appdomain was created by a program from our company. One approach is probably to use AOP and intersept all message calls, checking some pre condition, but this sounds like a lot of overhead. Are there any ways enable/disable AOP at runtime. For example veryfing the user at the first method call and then removing all method interceptions? Not really. Even if you could find a way to intercept all messages, there
would be no way to tell whether the evidence the app domain presents about itself is accurate or spoofed. Why are you concerned about the identity of the invoking code--licensing or trust issues? Show quote "MariusI" <Mari***@discussions.microsoft.com> wrote in message news:CD428E3F-52BB-4BCE-92FB-46A42382409F@microsoft.com... >I was wondering if there any security mechanisms in the framework which > enables me to identify the appdomain which my dll is being loaded into? > For > ex. if I want to make sure that the appdomain was created by a program > from > our company. > > One approach is probably to use AOP and intersept all message calls, > checking some pre condition, but this sounds like a lot of overhead. Are > there any ways enable/disable AOP at runtime. For example veryfing the > user > at the first method call and then removing all method interceptions? I want to do this to avoid third party vendors from putting a using statement
refering to our biz logic dll. Show quote "Nicole Calinoiu" wrote: > Not really. Even if you could find a way to intercept all messages, there > would be no way to tell whether the evidence the app domain presents about > itself is accurate or spoofed. Why are you concerned about the identity of > the invoking code--licensing or trust issues? > > > "MariusI" <Mari***@discussions.microsoft.com> wrote in message > news:CD428E3F-52BB-4BCE-92FB-46A42382409F@microsoft.com... > >I was wondering if there any security mechanisms in the framework which > > enables me to identify the appdomain which my dll is being loaded into? > > For > > ex. if I want to make sure that the appdomain was created by a program > > from > > our company. > > > > One approach is probably to use AOP and intersept all message calls, > > checking some pre condition, but this sounds like a lot of overhead. Are > > there any ways enable/disable AOP at runtime. For example veryfing the > > user > > at the first method call and then removing all method interceptions? > But why? Because you want to prevent folks from using your API without
paying a licensing fee or because you want your dll to be able to trust its calling code to have reliably performed some operation (e.g.: data validation or user authentication/authorization)? Show quote "MariusI" <Mari***@discussions.microsoft.com> wrote in message news:1CAD339F-12BE-4C64-BE7F-86D4B6232782@microsoft.com... >I want to do this to avoid third party vendors from putting a using >statement > refering to our biz logic dll. > > "Nicole Calinoiu" wrote: > >> Not really. Even if you could find a way to intercept all messages, >> there >> would be no way to tell whether the evidence the app domain presents >> about >> itself is accurate or spoofed. Why are you concerned about the identity >> of >> the invoking code--licensing or trust issues? >> >> >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message >> news:CD428E3F-52BB-4BCE-92FB-46A42382409F@microsoft.com... >> >I was wondering if there any security mechanisms in the framework which >> > enables me to identify the appdomain which my dll is being loaded into? >> > For >> > ex. if I want to make sure that the appdomain was created by a program >> > from >> > our company. >> > >> > One approach is probably to use AOP and intersept all message calls, >> > checking some pre condition, but this sounds like a lot of overhead. >> > Are >> > there any ways enable/disable AOP at runtime. For example veryfing the >> > user >> > at the first method call and then removing all method interceptions? >> Basically, to prevent folks from using my API in their own projects
Show quote "Nicole Calinoiu" wrote: > But why? Because you want to prevent folks from using your API without > paying a licensing fee or because you want your dll to be able to trust its > calling code to have reliably performed some operation (e.g.: data > validation or user authentication/authorization)? > > > "MariusI" <Mari***@discussions.microsoft.com> wrote in message > news:1CAD339F-12BE-4C64-BE7F-86D4B6232782@microsoft.com... > >I want to do this to avoid third party vendors from putting a using > >statement > > refering to our biz logic dll. > > > > "Nicole Calinoiu" wrote: > > > >> Not really. Even if you could find a way to intercept all messages, > >> there > >> would be no way to tell whether the evidence the app domain presents > >> about > >> itself is accurate or spoofed. Why are you concerned about the identity > >> of > >> the invoking code--licensing or trust issues? > >> > >> > >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message > >> news:CD428E3F-52BB-4BCE-92FB-46A42382409F@microsoft.com... > >> >I was wondering if there any security mechanisms in the framework which > >> > enables me to identify the appdomain which my dll is being loaded into? > >> > For > >> > ex. if I want to make sure that the appdomain was created by a program > >> > from > >> > our company. > >> > > >> > One approach is probably to use AOP and intersept all message calls, > >> > checking some pre condition, but this sounds like a lot of overhead. > >> > Are > >> > there any ways enable/disable AOP at runtime. For example veryfing the > >> > user > >> > at the first method call and then removing all method interceptions? > >> > se of sn.exe? > >\: > If this is basically an intellectual property issue, why not use a licensing
approach? If that seems like too much work, then the friend assemblies approach mentioned by dorminey might be suitable if you're using fx 2.0. If you're still using fx 1.1, it might seem tempting to use link demands for an identity permission (e.g.: StrongNameIdentityPermission), but be aware that these are quite easy for highly privileged code to bypasse, and they are automatically passed by fully trusted code under fx 2.0. Show quote "MariusI" <Mari***@discussions.microsoft.com> wrote in message news:AF9ADCA0-BDB8-43BD-BAA3-90EBD6345A9A@microsoft.com... > Basically, to prevent folks from using my API in their own projects > > "Nicole Calinoiu" wrote: > >> But why? Because you want to prevent folks from using your API without >> paying a licensing fee or because you want your dll to be able to trust >> its >> calling code to have reliably performed some operation (e.g.: data >> validation or user authentication/authorization)? >> >> >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message >> news:1CAD339F-12BE-4C64-BE7F-86D4B6232782@microsoft.com... >> >I want to do this to avoid third party vendors from putting a using >> >statement >> > refering to our biz logic dll. >> > >> > "Nicole Calinoiu" wrote: >> > >> >> Not really. Even if you could find a way to intercept all messages, >> >> there >> >> would be no way to tell whether the evidence the app domain presents >> >> about >> >> itself is accurate or spoofed. Why are you concerned about the >> >> identity >> >> of >> >> the invoking code--licensing or trust issues? >> >> >> >> >> >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message >> >> news:CD428E3F-52BB-4BCE-92FB-46A42382409F@microsoft.com... >> >> >I was wondering if there any security mechanisms in the framework >> >> >which >> >> > enables me to identify the appdomain which my dll is being loaded >> >> > into? >> >> > For >> >> > ex. if I want to make sure that the appdomain was created by a >> >> > program >> >> > from >> >> > our company. >> >> > >> >> > One approach is probably to use AOP and intersept all message calls, >> >> > checking some pre condition, but this sounds like a lot of overhead. >> >> > Are >> >> > there any ways enable/disable AOP at runtime. For example veryfing >> >> > the >> >> > user >> >> > at the first method call and then removing all method interceptions? >> >> >> se of sn.exe? >> >\: >> I'm using the 2.0 framework. I'm very interested in learning more about
licensing, ff you have some good links/resources regarding licensing, I would very much like to have them. Show quote "Nicole Calinoiu" wrote: > If this is basically an intellectual property issue, why not use a licensing > approach? If that seems like too much work, then the friend assemblies > approach mentioned by dorminey might be suitable if you're using fx 2.0. If > you're still using fx 1.1, it might seem tempting to use link demands for an > identity permission (e.g.: StrongNameIdentityPermission), but be aware that > these are quite easy for highly privileged code to bypasse, and they are > automatically passed by fully trusted code under fx 2.0. > > > "MariusI" <Mari***@discussions.microsoft.com> wrote in message > news:AF9ADCA0-BDB8-43BD-BAA3-90EBD6345A9A@microsoft.com... > > Basically, to prevent folks from using my API in their own projects > > > > "Nicole Calinoiu" wrote: > > > >> But why? Because you want to prevent folks from using your API without > >> paying a licensing fee or because you want your dll to be able to trust > >> its > >> calling code to have reliably performed some operation (e.g.: data > >> validation or user authentication/authorization)? > >> > >> > >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message > >> news:1CAD339F-12BE-4C64-BE7F-86D4B6232782@microsoft.com... > >> >I want to do this to avoid third party vendors from putting a using > >> >statement > >> > refering to our biz logic dll. > >> > > >> > "Nicole Calinoiu" wrote: > >> > > >> >> Not really. Even if you could find a way to intercept all messages, > >> >> there > >> >> would be no way to tell whether the evidence the app domain presents > >> >> about > >> >> itself is accurate or spoofed. Why are you concerned about the > >> >> identity > >> >> of > >> >> the invoking code--licensing or trust issues? > >> >> > >> >> > >> >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message > >> >> news:CD428E3F-52BB-4BCE-92FB-46A42382409F@microsoft.com... > >> >> >I was wondering if there any security mechanisms in the framework > >> >> >which > >> >> > enables me to identify the appdomain which my dll is being loaded > >> >> > into? > >> >> > For > >> >> > ex. if I want to make sure that the appdomain was created by a > >> >> > program > >> >> > from > >> >> > our company. > >> >> > > >> >> > One approach is probably to use AOP and intersept all message calls, > >> >> > checking some pre condition, but this sounds like a lot of overhead. > >> >> > Are > >> >> > there any ways enable/disable AOP at runtime. For example veryfing > >> >> > the > >> >> > user > >> >> > at the first method call and then removing all method interceptions? > >> >> > >> se of sn.exe? > >> >\: > >> > > For a quick intro, see
http://msdn2.microsoft.com/en-us/library/fe8b1eh9.aspx. For something a little more complete, you might want to take a look at http://www.developer.com/net/net/article.php/3074001, which does delve into more complex licensing scenarios after covering the basics of control licensing. If you only want to prevent others from using your code, simply writing your own LicenseProvider and generating licenses manually would probably be quite sufficient. However, if you're thinking of actually selling licenses to use your API, you might want to consider using a somewhat more complete licensing solution. There are a few listed at http://sharptoolbox.com/categories/licensing. Show quote "MariusI" <Mari***@discussions.microsoft.com> wrote in message news:36FE82E9-3CB4-46D5-9F21-A9D55AD02E66@microsoft.com... > I'm using the 2.0 framework. I'm very interested in learning more about > licensing, ff you have some good links/resources regarding licensing, I > would > very much like to have them. > > "Nicole Calinoiu" wrote: > >> If this is basically an intellectual property issue, why not use a >> licensing >> approach? If that seems like too much work, then the friend assemblies >> approach mentioned by dorminey might be suitable if you're using fx 2.0. >> If >> you're still using fx 1.1, it might seem tempting to use link demands for >> an >> identity permission (e.g.: StrongNameIdentityPermission), but be aware >> that >> these are quite easy for highly privileged code to bypasse, and they are >> automatically passed by fully trusted code under fx 2.0. >> >> >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message >> news:AF9ADCA0-BDB8-43BD-BAA3-90EBD6345A9A@microsoft.com... >> > Basically, to prevent folks from using my API in their own projects >> > >> > "Nicole Calinoiu" wrote: >> > >> >> But why? Because you want to prevent folks from using your API >> >> without >> >> paying a licensing fee or because you want your dll to be able to >> >> trust >> >> its >> >> calling code to have reliably performed some operation (e.g.: data >> >> validation or user authentication/authorization)? >> >> >> >> >> >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message >> >> news:1CAD339F-12BE-4C64-BE7F-86D4B6232782@microsoft.com... >> >> >I want to do this to avoid third party vendors from putting a using >> >> >statement >> >> > refering to our biz logic dll. >> >> > >> >> > "Nicole Calinoiu" wrote: >> >> > >> >> >> Not really. Even if you could find a way to intercept all >> >> >> messages, >> >> >> there >> >> >> would be no way to tell whether the evidence the app domain >> >> >> presents >> >> >> about >> >> >> itself is accurate or spoofed. Why are you concerned about the >> >> >> identity >> >> >> of >> >> >> the invoking code--licensing or trust issues? >> >> >> >> >> >> >> >> >> "MariusI" <Mari***@discussions.microsoft.com> wrote in message >> >> >> news:CD428E3F-52BB-4BCE-92FB-46A42382409F@microsoft.com... >> >> >> >I was wondering if there any security mechanisms in the framework >> >> >> >which >> >> >> > enables me to identify the appdomain which my dll is being loaded >> >> >> > into? >> >> >> > For >> >> >> > ex. if I want to make sure that the appdomain was created by a >> >> >> > program >> >> >> > from >> >> >> > our company. >> >> >> > >> >> >> > One approach is probably to use AOP and intersept all message >> >> >> > calls, >> >> >> > checking some pre condition, but this sounds like a lot of >> >> >> > overhead. >> >> >> > Are >> >> >> > there any ways enable/disable AOP at runtime. For example >> >> >> > veryfing >> >> >> > the >> >> >> > user >> >> >> > at the first method call and then removing all method >> >> >> > interceptions? >> >> >> >> >> se of sn.exe? >> >> >\: >> >> >> >> I would be interested to hear why you want to do this. If you just
need to make sure that your callers are from a list of predefined assemblies you could use the System.Runtime.CompilerServices.InternalsVisibleTo attribute to list any assemblies able to call your library and have any class that you want protected be marked as internal. This wouldn't give you the ability to just run whenever a new AppDomain from your company called your code but a more granular level of control might be what you want. MariusI wrote: Show quote > I was wondering if there any security mechanisms in the framework which > enables me to identify the appdomain which my dll is being loaded into? For > ex. if I want to make sure that the appdomain was created by a program from > our company. > > One approach is probably to use AOP and intersept all message calls, > checking some pre condition, but this sounds like a lot of overhead. Are > there any ways enable/disable AOP at runtime. For example veryfing the user > at the first method call and then removing all method interceptions? I want to do this to avoid third party vendors from putting a using statement
refering to our biz logic dll. You solutions seems to be what i'm looking for, than you. Show quote "dormi***@gmail.com" wrote: > I would be interested to hear why you want to do this. If you just > need to make sure that your callers are from a list of predefined > assemblies you could use the > System.Runtime.CompilerServices.InternalsVisibleTo attribute to list > any assemblies able to call your library and have any class that you > want protected be marked as internal. > > This wouldn't give you the ability to just run whenever a new AppDomain > from your company called your code but a more granular level of control > might be what you want. > > > MariusI wrote: > > I was wondering if there any security mechanisms in the framework which > > enables me to identify the appdomain which my dll is being loaded into? For > > ex. if I want to make sure that the appdomain was created by a program from > > our company. > > > > One approach is probably to use AOP and intersept all message calls, > > checking some pre condition, but this sounds like a lot of overhead. Are > > there any ways enable/disable AOP at runtime. For example veryfing the user > > at the first method call and then removing all method interceptions? > >  |
|||||||||||||||||||||||
Other interesting topics