On Friday 24 Jan 2003 8:11 pm, Matthew Toseland wrote: > > > Eventually, we will implement somse sort of server > > > side scripting... with a couple of limits it could be reasonably safe. > > > > Do you mean node scripting? Or do you mean routed single-server style > > access? The latter would always be voulnerable to routing analysis to > > some extent. But, this is probably too small a risk to worry about in a > > very busy network, as there is no way what connection is for what. > > I mean running limited scripts on a VM in fproxy.
So that would be "client node side", then? :-) > > But if node-side scripting exists instead, then that means that ANY node > > can download and execute script code to serve a request. This would be a > > fantastic solution for hugely distributed web applications with near > > infinite scalability (any node can run any script, just like it can serve > > any file request, provided it has it). > > Err, maybe. Well, surely not if it runs in fproxy, unless the node itself gets given a way to execute an arbitrary piece of code within the VM in fproxy, which is pribably a bad idea. > > Have you considered using the Rhino Java based JS interpreter? That would > > be a very "cool" feature. > > Thanks for the tip. Somebody was going to implement it but it was too > early and they disappeared. Can you make a guess as to when the time will be about right to start seriously thinking about it? > > As far as algorithms and optimizations are concerned, however, all four > > approaches (fred servlet, fred scripting, browser scripting, > > standalone app) would be pretty much the same. Fred servlet idea has > > merits in the fact that there will be no filter complaints. > > They are not equivalent in security. We cannot allow any javascript code > to pass to the browser because we cannot tell what it might make the > browser do, and the browser generally isn't very cautious about letting > javascript open web pages from other hosts etc. True. Is there something to stop a servlet running in fred from doing something similar? JS is certainly more secure than a separate, standalone application, because it at least cannot access the file system. > > I think I like the fred scripting idea best, because it has all the > > advantages of the other approaches, but is additionaly the most scaleable > > one, because any node could serve a request. This could also be used to > > move the process to the data, rather than always moving the data to the > > process. The downside is that if there is a security exploit, ALL of the > > nodes would compromised almost immediately. So, if something goes wrong, > > it's time to re-initialize ALL the nodes... :-( > > It would run on the fproxy, not on the node. OK, that makes a lot of sense. > The requesting fproxy would have to run the code. Given that it can only > access a few limited methods, it could be made reasonably safe. For > example, we don't want to let it set HTLs for requests of 0. We also > don't want it to be able to run parallel requests and see which happens > first. Either of these would allow anonymity compromize by various > attacks. Indeed. There is a problem over preventing parallel requests, because that would be the only plausible way to do certain things in a reasonable amount of time. This could be worked around to some extent by providing a built in method to download multiple files in parallel, but only get them back after they have all downloaded, or failed. But then again, wouldn't it be just as harmful to repeatedly request different files and time them one by one, and get timing information that way, statistically analyzed if necessary? How are parallel requests worse in this regard? > > > We might just allow some client-side stuff, but only "trusted recipes". > > > > How would these be identified? Keeping a list of "trusted" sites? > > No. Keep a list of (parametized) trusted strings of javascript. Simple > things like rollovers or whatever. Hmm... I have to say I hate that idea, but I cannot think of any other way to be suitable paranoid. Perhaps there could be a standard javascript library which could be approved? Then the library file could get checked against it's MD5 signature before the filter would let it run? Or just have it as a regularly inserted CHK, which already has an SHA hash of itself in it's name, so you would only have to let the filter know that this key is OK. It may also be an idea to make the safe js key list an option in the configuration file, rather than hard-coded. > > > Help with this would be greatly appreciated :) > > > > Which part? I'd be happy to lend a hand here and there as far as coding > > is concerned, especially if it would help with getting features such as > > node-side scripting to work. I am concerned, however, with the danger > > that could potentially cause to the network should a security exploit > > exist... > > Help with integrating rhino into fproxy would be useful. You'd need to > collude with me quite a bit because of security and portability/bundling > issues. Sure. I cannot promise exactly when and how much I would be able to work on this, but I'd be willing to give it a try. Should we take this up on a different list? Or off-list? Regards. Gordan _______________________________________________ Tech mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/tech
