none
Security dilema RRS feed

  • Question

  • I'm trying to implement some security in my assemblies to control who can call the methods exposed. Now i've been playing around with StrongNameIdentityPermissionAttribute but due to FullTrust this doesn't work :(.

    So i decided to try something different. My new approach is that i crawl thru the call stack myself and check that the caller is either signed with the correct strong name or that the calling assembly is from microsoft. Now this works a treat except how can i tell that the asembly is from MS? I started with looking at the publickey token (but there a a number of these) i then went for a combination of token and assembly name (but this approach is quite poor as any fool could release an assembly with the name Microsoft in it...)

    I suppose i'm after a general guidence with my approach. If you have a better suggestion then please tell me, i've been joining around in circles for a while now and i would appreciate a fresh 'look' at this. Please note that these assemblies are not going to be released to the public, these are only for use inside the company. All i'm after really is for the ability to stop the casual developer binding to my assemblies without permission.

     

    Thanks,

    Cedric

     

    Monday, March 29, 2010 2:57 PM

Answers

  • One big warning about your approach: Call stack is not evidence which code called your code, but rather where your code will continue when it returns (ideally it should be named 'return stack'). Cross-module inlining and tail calls can leave out your callers from the call stack. Using call stack to determine security-sensitive stuff based on your caller is dangerous and STRONGLY not recommended.

    It is almost guaranteed to not work in all cases - for example a new version of CLR (e.g. new service pack) with more aggresive inlining/tail calling can easily break your security assumptions and create a security hole (in your case create more troubles than you wanted to have).

    -Karel

    Tuesday, March 30, 2010 5:30 AM
    Moderator
  • There's no way of using a wildcard in the InternalsVisibleTo attribute. Rebuilding the base assembly everytime you create a new assembly is only a problem if you're constantly creating new assemblies. Anyway, I don't see any other workaround, unless you're willing to consider a roundtrip to disassemble the main assembly and inject the IL for dynamically generating the InternalsVisibleTo attributes referencing all the dependent assemblies, but that's just plain overkill!
    -- Blog: http://geeklyeverafter.blogspot.com/
    Tuesday, March 30, 2010 1:18 PM

All replies

  • Why do you need to avoid binding with your assemblies? If what you're attempting to do is allowing another of your own assemblies to access something that others shouldn't be able to do, then you should mark the target methods/classes as internal and use the InternalsVisibleTo attribute, so that your main assembly specifies that it's internal members are accessible to your second assembly.

    Does this suit your needs, or do you have any other requirements that don't suit the friendly assemblies approach?


    -- Blog: http://geeklyeverafter.blogspot.com/
    Monday, March 29, 2010 3:04 PM
  • One big warning about your approach: Call stack is not evidence which code called your code, but rather where your code will continue when it returns (ideally it should be named 'return stack'). Cross-module inlining and tail calls can leave out your callers from the call stack. Using call stack to determine security-sensitive stuff based on your caller is dangerous and STRONGLY not recommended.

    It is almost guaranteed to not work in all cases - for example a new version of CLR (e.g. new service pack) with more aggresive inlining/tail calling can easily break your security assumptions and create a security hole (in your case create more troubles than you wanted to have).

    -Karel

    Tuesday, March 30, 2010 5:30 AM
    Moderator
  • Bruno,

    The issue that we uffer from is that our team shares servers with a number of other teams and no matter how many time we tell the other to not bind to our assemblies they do. This all came to a head a couple of of weeks ago when did a production release of our software with some major changes and we broke there software. And since I've personnally had enough of being shouted at for braking production we are now looking at ways to stop unautherised usage of the libraries.

    I did look into the use of InternalVisibleTo, as we already use this for a couple fo things, but unfortunately that would not work for us in this scenario. It would mean a rebuild of the base libraries everytime we realease new software (which is pretty much every week....)

    I'm not hot on the licensing model in .net, would that maybe work for me?

    Cedric

    Tuesday, March 30, 2010 8:21 AM
  • Karel,

    A fair point well made. I didn't see that coming... Bugger.

    It's a shame that MS changed StrongNameIdentityPermission to be basically ignored in a fulltrust...

    Any other suggestions?

     

    Cedric

    Tuesday, March 30, 2010 8:26 AM
  • I did look into the use of InternalVisibleTo, as we already use this for a couple fo things, but unfortunately that would not work for us in this scenario. It would mean a rebuild of the base libraries everytime we realease new software (which is pretty much every week....)

    You must be doing something wrong, because the InternalsVisibleTo attribute doesn't make you rebuild all the libraries as long as you don't change the public key token of your dependent assemblies (which you definitely shouldn't do!)
    -- Blog: http://geeklyeverafter.blogspot.com/
    Tuesday, March 30, 2010 10:30 AM
  • Bruno,

    Sorry, didn't explain myself properly. The issue with using this method is that you need to add in your base assembly the attibute to allow the dependent assemblys to access the internals. As new assemblies are released which use the functions in the base assemblies we would need to rebuild the base assembly with the InternalsVisibleTo attribute for the new assembly.

    Unless there is a way of adding a wildcard assembly to the InternalsVisibleTo attribute.

     

    Thanks,

    Cedric

    Tuesday, March 30, 2010 10:45 AM
  • There's no way of using a wildcard in the InternalsVisibleTo attribute. Rebuilding the base assembly everytime you create a new assembly is only a problem if you're constantly creating new assemblies. Anyway, I don't see any other workaround, unless you're willing to consider a roundtrip to disassemble the main assembly and inject the IL for dynamically generating the InternalsVisibleTo attributes referencing all the dependent assemblies, but that's just plain overkill!
    -- Blog: http://geeklyeverafter.blogspot.com/
    Tuesday, March 30, 2010 1:18 PM
  • Hi Cedric,

     

    Bruno's posts are really helpful on this case.  Would you mind letting us know how is the problem?    

    If you need further assistance, please feel free to let me know.   I will be more than happy to be of assistance.

     

    Have a nice day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, April 6, 2010 2:32 AM
    Moderator