On Nov 27, 2009, at 5:10 AM, Dr. David Kirkby wrote: > kstueve wrote: >> >> On Nov 25, 12:34 pm, "Dr. David Kirkby" <david.kir...@onetel.net> >> wrote: >>> It would appear to me that it would be very easy for a "script >>> kiddie" to write >>> a a program which created huge numbers of accounts on a Sage >>> server, perform >>> some CPU intensive computation on them, and bring the system to a >>> near >>> standstill. This is generally known as a denial of service attack. >>> >>> I wonder if there should be some sort of question that only a >>> human can answer, >>> before an account is created. I find some of the sites which use >>> obfuscated >>> letters and numbers almost impossible to use, as the degree of >>> obfuscation is >>> too large. >>> >>> As Sage gets better known, the chances of this happening only >>> increase. >> Someone might even try creating Sage worksheets that function as >> vectors for spam. >> > > One one around that is to block outgoing traffic on port 25 with a > firewall, but > of course, that is not much use if you want to be able to send mail > from the > machine. > > On Solaris one can block outgoing ports in a zone, without affecting > the rest of > the machine. In fact, if someone gets root access in a zone, they > can do no > damage elsewhere. > > I know one of the BSD's supports a 'jail', where again the same > could be done. I > do not know about Linux, but perhaps it has a similar system, where > you can run > an insecure service in a zone/jail/restricted area, so any hacker > can't do much > damage.
We run the whole notebook inside a VM, which means it'd be really difficult to get out and cause damage on the hosting machine. There needs to be better support for isolating user processes from the notebook process and from each other. I think the real concern is, however, spammers using the cpu and network connection from the notebook to send emails, host fake webpages, do cross-site scripting attacks, etc. rather than hijack the notebook server machine itself. In fact, if they're doing the above, it's best not to disrupt the normal server operation so as to go longer unnoticed. > Perhaps there is a project there, to get a computer science student > to find all > the ways to attack a Sage server, and then fix any problems. Actually, someone did a Masters project on just this. > > If you serve only static pages, it is very difficult for someone to > attack a web > server. But once you start supporting scripting languages like PHP, > or CGI > scripts, the avenues for attack increase. I would see Sage would > fall into the > latter category. Especially as each notebook cell is as good as a shell account already :) - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
