See inline.
_____ From: Matt Valerio [mailto:[EMAIL PROTECTED] Sent: Friday, September 14, 2007 3:01 PM To: Dusty Candland - eonBusiness Cc: Anton Melser; [email protected] Subject: Re: [Alchemi-developers] ideas for a dll cache Hey everyone, On 9/14/07, Dusty Candland - eonBusiness <[EMAIL PROTECTED]> wrote: I would prefer the AGAC (maybe just call it the AAC) over storing dll's in a database. I've not used db4o, but using a db seems like a lot of overhead where the file system should work fine. Yes, the Alchemi Assembly Cache (as opposed to the Global Assembly Cache) is a good distinction to make. Using db4o does feel like overkill in this situation because the Fusion (the assembly loader) just looks in a certain folder. Secondly, how will other resources be handled? Things like config files and other non dll resources. I guess everything could be required to be included as an embedded resource. Another option would be to run a crypo-hash (like MD5) on the files and use that value for the key in the cache in place of the signed assembly full name. That's a very good point. I think that only assemblies should be cached. This is the bulk of the binary data going over the wire. Config files and other text files can still be FileDependencies. The only situation I could forsee where you'd want to cache non-assembly resources is if you had a grid application that had one extremely large input file (like an image or audio file or video or something to process) that was shared between all of the executors. This seems to be a fringe case though -- you could still write code in the thread that downloads the image from a certain URL or something. Any other ideas about how to handle non-assembly resources? I vote that we only cache assemblies and require everything else be FileDependencies. [Dusty] I agree. How would the grid handle un-signed dll's? Just not cache them? That's a fine solution for me, but then there are two code paths. I guess what I'm getting at is some consideration should be given regarding development for the grid. Further, minimizing the requirements to get something to run initially has some value. Good point. I suppose that it is quite unreasonable to require that all cached assemblies be signed. Because that would imply that all code using the assemblies that need cached are signed, and that is a strict requirement that would severly limit the places where Alchemi can be used. The system that I described would still work for unsigned assemblies -- just that instead of PublicKeyToken=<random string of hex digits>, it is just null. (just the output of the Assembly.FullName property...) I think it would be beneficial to just have one method of operation, and handle signed/unsigned cases the same. [Dusty] I agree one way to handle caching files is good. [Dusty] I suppose we need to have a more in-depth discussion about the security implications of the caching. What kinds of attacks is this method vulnerable to? One situation I can think of is this: A trusted GThread that relies on an image processing assembly (ImageLib.dll) is deployed (and cached) to all of the executors that processes an image. It's unsigned, so you can't tell if it's been tampered with or changed. An attacker could then notice that the DLL is cached on the system, and that the image processing GThread is uses every night between 2 and 3am to run some scientist's jobs. The attacker could then open ImageLib.dll in Reflector and see what the classes were called, and then write his own code into another malicious assembly with the same function signatures. Then the attacker could simply copy his malicious into the AAC and overwrite the existing (good) ImageLib.dll. When the Gthread is run that night, the malicious code is executed. So, yes, Dusty's idea of implementing a hash of the assembly (esp. if it's unsigned) is a good idea. How exactly would that work? [Dusty] What you describe is the main attack that I can see as well. Using the built in crypto stuff we can get a hash of the file, binary or not and store that in the cache. I like using strong names better because the framework takes care of it and checks when loading the assemblies. Plus it has the added protection of signing not just the hash. What about a slightly different approach, in which only signed assemblies get cached and non-signed just work they way they do today along with other file dependencies? Maybe have an AssemblyDependency class which takes care of checking it is signed and if so then cache it? Are there any other scenarios that we should be looking into? -Matt ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Alchemi-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-developers
