here is another question (kurt already knows about it). i would like to do a client server version of R where the server can run on a unix box and the client is excel ond a win machine. the easiest solution would be running a stdin-stdout version of the server through inetd. but this is vulnerable. so what is needed is a sandbox version of the server, where no acrtive access to the file system is open and where spawning processes is disabled. are there any plans for doing such a version? -- Erich Neuwirth, Computer Supported Didactics Working Group Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-38624 Fax: +43-1-4277-9386 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Erich Neuwirth <erich.neuwirth@univie.ac.at> writes:> here is another question (kurt already knows about it). i would like > to do a client server version of R where the server can run on a > unix box and the client is excel ond a win machine. the easiest > solution would be running a stdin-stdout version of the server > through inetd. but this is vulnerable. so what is needed is a > sandbox version of the server, where no acrtive access to the file > system is open and where spawning processes is disabled. are there > any plans for doing such a version?No immediate plans no. It sounds a bit dangerous with dyn.load and whatnot floating around. What would be more likely to work would be to have a version of R that would immediately chroot() to a directory specified on the command line and an inetd.conf entry like auth stream tcp nowait nobody \ /usr/sbin/tcpd in.Rdaemon --chroot=/usr/lib/Rdaemon and setup /usr/lib/Rdaemon as a "chroot jail" with no write permissions and /bin and /lib subdirectories with only the few system commands and .so files needed to run (if there are any), and with an /RHOME tree with packages and soforth. That way, it could do little damage apart from eating CPU cycles. (Much like the way in which anonymous FTP is set up). -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Wed, 15 Mar 2000, Erich Neuwirth wrote:> here is another question (kurt already knows about it). > i would like to do a client server version > of R where the server can run on a unix box and the client > is excel ond a win machine. > the easiest solution would be running a stdin-stdout version > of the server through inetd. > but this is vulnerable. > so what is needed is a sandbox version of the server, > where no acrtive access to the file system is open > and where spawning processes is disabled. > are there any plans for doing such a version?This would be very hard to do properly. It's certainly possible to disable the interpreted commands that access the file system, and even to remove them from the symbol table so that .C and .Internal can't get to them. This would stop accidental damage or casual attacks. However I don't think we can disable .C/.Fortran completely. By passing data of the wrong types to .C a sufficiently malicious program can overwrite the stack and get with very little effort the sort of effect that usually takes buffer overflows. I think a secure version of R would require rewriting all the important .C and .Fortran code to use Internal or .Call and then disabling .C and .Fortran as well as system() and all the file access commands (or perhaps restricting the file access to a specific tree as http servers do). In the foreseeable future I think the solution is to assume that R can execute arbitrary code and either run in a safe account or authenticate the connection somehow. -thomas -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Erich Neuwirth wrote:> here is another question (kurt already knows about it). > i would like to do a client server version > of R where the server can run on a unix box and the client > is excel ond a win machine. > the easiest solution would be running a stdin-stdout version > of the server through inetd. > but this is vulnerable. > so what is needed is a sandbox version of the server, > where no acrtive access to the file system is open > and where spawning processes is disabled. > are there any plans for doing such a version? >You could have a look at some of the things Jeff Banfield did for Rweb (http://www.math.montana.edu/Rweb). He disabled some things to get a moderate increase in security, but as Thomas and Peter said, you really can't drop dyn.load and .C and with those more or less anything is open to someone who knows what they are doing. luke -- Luke Tierney University of Minnesota Phone: 612-625-7843 School of Statistics Fax: 612-624-8868 313 Ford Hall, 224 Church St. S.E. email: luke@stat.umn.edu Minneapolis, MN 55455 USA WWW: http://www.stat.umn.edu -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Wed, Mar 15, 2000 at 04:20:26PM +0100, Erich Neuwirth wrote:> here is another question (kurt already knows about it). > i would like to do a client server version > of R where the server can run on a unix box and the client > is excel ond a win machine. > the easiest solution would be running a stdin-stdout version > of the server through inetd. > but this is vulnerable.It isn't too bad if you feed it through the /usr/sbin/tcpd service which can screen incoming connections (various filtering rules go into /etc/hosts.allow and /etc/hosts.deny, see the man page for tcpd). If your local network keeps static IP numbers then add all the acceptable machines into your /etc/hosts file so you have a local copy of their IP numbers and no one can use the DNS to confuse your machine, also make sure nothing nearby has source-routing switched on. That is reasonably secure if you can trust the machines which you are allowing connections from and your routers are set up in a way that they cannot get confused. It is still possible for someone to clip their laptop to the local network, use a false IP number and maybe make a connection but this is pretty unlikely and you probably will see the person doing it (unless your local network is completely insecure like ours). Naturally, using a chroot is a good idea and creating a local unix user that does only this and owns no files except its own tree is also a good idea. - Tel -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._