locked
Securing Dynamically Loaded and Service-Bound Parts RRS feed

  • Question

  • We are developing an application that supports dynamic loading of parts (kind of like the PortalBase sample). 

     

    My question is: given that we are doing dynamic service binding, what are the recommended ways of securing access to certain services?  Dynamically loaded (and therefore unknown) parts could 'reach into' acropolis and access any services available?

    Wednesday, August 22, 2007 2:39 PM

Answers

  •  

    The topic of dynamically loaded parts is a frequent one we have here on the team as it carries with it whole host of opportunities for powerful scenarios as well as a whole slew of interesting problems and pitfalls.  Currently we haven’t landed on an exact design for this yet and we’re still working through all the various possibilities.  At this early stage of the product, any input that you have is certainly welcome (what are your scenarios, how would you like to see it work, major concerns you’d like to see addressed, etc…)

    I can summarize some of the thinking we’ve done so far and some of the issues we see around dynamic behavior.  The major areas of interest around dynamic behavior center on these topics:

    ·         Trust/Security – Do you trust the author of the assembly that you’re dynamically loading?

    ·         Performance – How important is performance around the dynamic behavior? Isolation and secure sandboxing usually come with a performance penalty.

    ·         Reliability – How do I know the thing that I just loaded will work?  Versioning issues, required services being met, etc…

    ·         Discovery – How does the system know what to do with the stuff that was just loaded?  What should be automatically created and wired, what should just be ‘registered’ but not yet created, etc…

    Each area is an entire line of research and design in and of itself, with ramifications in all the other areas as well (which is what makes this topic such a frequent one).  Since your question centers around the first area let’s explore that in a little more detail.

    Security

    There are three main archetypes of dynamic behavior that affect security (the primary concern of your original question).

    1)      The application is just choosing to dynamically load parts of itself for various reasons (usually performance), so the assemblies while being loaded dynamically, can still be considered a ‘trusted’ part of the application.

    2)      The application is loading previously unknown assemblies that the user has discovered on their own and chosen to load, but the assemblies themselves are signed by a trusted provider and confirm to a well behaving component.

    3)      The application is truly loading an unknown assembly from an unknown location/publisher.

    From a security standpoint the first 2 scenarios already have a front line security mechanism built in, the trusted signature of a reliable software provider.  So for those 2 scenarios it’s probably enough that we just prevent ‘honest mistakes’ from happening.  Meaning that if the runtime does its job correctly, the dynamically loaded parts should get wired up to the correct services and should not get wired up to any services that the application has not made readily available (via our scoping mechanism).

    For the 3rd scenario however, things get a little dicey since there is no trust.  If you load that assembly into your main application domain, then all bets are off as there is nothing the runtime can do to prevent that component from reaching out and playing with any object also living in that domain.  Again, we can prevent honest mistakes, but malicious code has access to the entire app domain and will be able to start partaking in whatever mischief its security access will allow.

    So to be truly safe, assemblies that fall into the 3rd category will have to be loaded into their own AppDomain and the application will have to carefully and purposefully decide what services to make available in that secondary domain.  The Acropolis runtime framework can’t do all this magically for you since it has no idea what you consider to be a safe service and what you consider to be a sensitive service, what services should be recreated in the app domain and what services should be ‘proxied’ via remoting into the new app domain, etc...  But we believe there are some things that the framework can do to at least make this easy/easier for the application to do.

    Again any input/ideas you have on the scenarios and/or the design are more than welcome!

    Thanks,

    Tuesday, August 28, 2007 4:35 PM