On Mon, 30 Apr 2007, Mike Fitzpatrick wrote:
> Well, "no way" might be a little strong. If you're really so worried that
> somebody will hack your machine for the sole purpose of spoofing a
> plastic message to send an 'rm' command, then implement some sort
> of filter on the general commands allowed by an app to protect itself.
All right, "very difficult". I did consider the options for attempting to configure Tcl so that it would execute a sufficiently large subset of useful commands but block access to "exec" and file deletion commands, but it's not easy. For the application in question, remote control was achieved by sending a snippet of Tcl which was executed by the same interpreter which was running the GUI. The intention of this was to provide fine control of the application to do things like change plotting styles, load configuration files, overplot contours and so on, and that's a sensible way to do it in Tcl, and acceptably safe if you know it's only the user of the application process who can specify such commands.
> Does anybody seriously believe this is gonna be an issue in the
> real world, and more importantly, one that we need to deal with NOW??
All I can say is that I considered it a serious enough problem to spend several days thinking about and then coding around. If I hadn't it would have been quite possible for a student to write a program which sat around looking for a PLASTIC service, when it found one waited for a GAIA application to connect, and then send rm -r. The only difficult part would have been knowing that the security loophole existed, which I admit is a remote possibility for now. Yes, this is only an issue on a multi-user machine, but at my university at least, these do exist and people do work on them.
Mark
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2007-04-30Z11:36:01