On Tue, 16 Jan 2001, Daniel A. Koepke wrote: >Restricted execution, restricted execution, restricted execution. Any >system that is going to rely on a bunch of small programs kindly >interacting has to have a way for a trusted application to spawn an >untrusted child safely. That is, build a sandbox for the child to play >in and not be able to do any harm. Something like chroot() would be nice, but it unfortunately requires root access. Since we really, really do not want such access we can't. The best might be forking off a setuid root helper app as you alluded to that we tunnel the connection to. The little helper would set up the jail and run the editor with lowered permissions. It's a lot easier to audit the little helper application than all of the MUD itself. >At the same time, I think it's feasible that, through sufficient limits >on capabilities, you could give someone a full-blown shell and have a >reasonable assurance that they're not doing anything that will hurt *too* >much. Of course, I wouldn't do it. FreeBSD has jail() for this purpose. Most other Unix systems will at least have chroot() to use. ptrace() would be...interesting to use. As people might be able to tell...possible but not first on the list to do for security reasons. -- George Greer greerga@circlemud.org -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/03/01 PST