On Fri, Jan 24, 2003 at 09:01:56PM +0000, Gordan Bobic wrote: > 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? No. But that's a standalone application (sorta). We can't stop users installing standalone apps, but at least we are not responsible for them. > > JS is certainly more secure than a separate, standalone application, because > it at least cannot access the file system. Javascript can however access the internet. THAT is the problem. > > > > 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. Yeah, if we implement the request pool thing, we could have a method to do parallel requests. It would have to return after all had succeeded or failed, without any indication as to which came first. > > 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? Yeah, we might have to disable the clock too. > > > > > 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
-- Matthew Toseland [EMAIL PROTECTED][EMAIL PROTECTED] Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at ICTHUS.
msg01077/pgp00000.pgp
Description: PGP signature
