Thanks for answers. What we are currently doing: - integrate some vm patches (thanks Mariano :) from netstyle / seaside hosting which limit file system / socket access - try to run hosted images in another account
It seems chrooting each account is not so easy. Yes, would be nice to make SmallHarbour running on FreeBSD. Laurent. On Mon, Aug 8, 2011 at 9:37 AM, Miguel Moquillon <[email protected] > wrote: > If the host of SmallHarbour is running with FreeBSD 8 or Solaris, you can > use the "capabilities" feature to give restrictive priviledges to the > program or to some parts of the program. In short a capability is a pair of > a reference to an object in the system with the rights on that object. You > can allocate to the program a set of capabilities that define the security > environment within which it will run. > > Mig > > Le 06/08/2011 14:31, Dale Henrichs a écrit : > > Laurent, >> >> I think that the best defense is the limited access/rights unix account, >> perhaps even a separate unix user per account (to provide isolation between >> accounts) ... I think this is what VMware does in in its Cloud Foundry ... >> to be completely safe you'd have to turn off the ability to read and write >> files and turn off socket access (this is what javascript in the browser >> does), but going this far severely limits what you can do in the image ... I >> would think that you could screw things down pretty tight just using unix >> permissions .... >> >> Dale >> >> ----- Original Message ----- >> | From: "laurent >> laffont"<laurent.laffont@**gmail.com<[email protected]> >> > >> | To: "Seaside - developer >> list"<seaside-dev@lists.**squeakfoundation.org<[email protected]>>, >> "An open mailing list to discuss any topics >> | related to an open-source Smalltalk"<pharo-project@** >> lists.gforge.inria.fr <[email protected]>> >> | Sent: Saturday, August 6, 2011 3:06:38 AM >> | Subject: [Pharo-project] Web app security >> | >> | Hi, >> | >> | >> | with a public SmallHarbour (public fork of SeasideHosting - >> | smallharbour.org ) people can upload images that do bad things: >> | change filesystem, run commands, .... >> | >> | >> | Actually, what are the ways of securing a server so people can't do >> | bad things ? >> | >> | >> | I'm thinking of: >> | - run the vm/image within a low right unix account >> | - remove dangerous plugins (OSProcess, ?) >> | >> | >> | Can we easily chroot ? >> | >> | >> | what are known solutions ? >> | >> | >> | Laurent. >> >> > >
