+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 <dhenrich@vmware.com> 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" <laurent.laffont@gmail.com>
| To: "Seaside - developer list" <seaside-dev@lists.squeakfoundation.org>, "An open mailing list to discuss any topics
| related to an open-source Smalltalk" <pharo-project@lists.gforge.inria.fr>
| 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.