+1. but in this way, you will be protect the "external" enviroment.(filesystem, process,etc)
you have the internal enviroment risks.. in the image.. I think, the best way, is generate some like a sandbox.. a filesystem segment and image segment with the "Inmutables Object".. where the user can't change the instances/objects and others where the user playing. Best D. http://about.me/diogenes.moreira On Sat, Aug 6, 2011 at 9:31 AM, Dale Henrichs <[email protected]> wrote: > 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" <[email protected]> > | To: "Seaside - developer list" <[email protected]>, > "An open mailing list to discuss any topics > | related to an open-source Smalltalk" < > [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. > >
