This project has moved and is read-only. For the latest updates, please go here.

Securing the DirectoryCatalog

Jan 1, 2010 at 11:04 AM

I wrote post that was describing 3 possible techniques for securing MEF from maliciouscode

the problem is that the main technique involve minor change to the Directory Catalog

(it is all described in the post).

this is a call to the MEF team to consider adding those minor changed into the release bits.

I think that security hole may prevent smoothly adaption of MEF.

I would like you hering your opinions on this subject.

Jan 1, 2010 at 11:20 AM
Edited Jan 1, 2010 at 11:34 AM

HI Bnaya.

We talked abou this many times, and deliberately did not add such a catalog mainly because we felt whatever path we chose would only satisfy a small handful of needs. Additionally every time we add an extensibility point, it dramatically increases our test cost, and poses security risks as we increase our attack surface. For this reason we never take extension points lightly.

DirectoryCatalog is really syntactc sugar. Creating your own secure catalog is actually quite easy, the reason is because we have an AssemblyCatalog, TypeCatalog and AggregateCatalog, all of which give you full capability to secure assmblies.

1. You can write a custom routine that scans through all assemblies in a folder and then only loads the assemblies that are signed with a specific key. Once you have those assemblies, you create an AssemblyCatalog for each one that you want to let in. Add those catalogs to an AggregateCatalog and then give that Aggregate to the container, voila, you've lockled down your assemblies. You don't even need a custom catalog do to this, you just need a helper method that you point to some directory and it returns for you an aggregate catalog, something like GetAggregateCatalog for example. It's probably about 10 to 15 lines of code max. Using a key is just one of many mechanisms you could use, you could decide to check if it is on an acceptable list, in an acceptable namespace, etc, etc.

2. A variation of the first, instead of loading up all the assemblies, you actually inspect each assembly and you look at each type checking for an attribute that indicates it's required license. Then you create TypeCatalogs for each type that is permitted based on the apps license. All the type catalogs are then added to an aggregate.

These are just 2 ways out of many possible approaches to solving the problem. Each application has different needs, but they can easily implement the ones that suit their needs.


Jan 2, 2010 at 6:11 AM


Jan 7, 2010 at 7:03 AM

I took Glenn advice and build the secure directory catalog (which I will publish soon) upon the aggregate catalog
however I'm having a minor limitation comparing with the source code of the
directory catalog.
the directory catalog creating its underline assembly catalog using the folloing constructor:
internal AssemblyCatalog(Assembly assembly, ICompositionElement definitionOrigin)
which having an internal modifier, as result custom catalogs cannot claim for being the definition origin of nested catalogs.

My question to the MEF team is what does the definition origin is used beyond diagnostic purpose?
And do you think that custom catalog should use it somehow?