[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.
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.
+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.
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> | 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.
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 <miguel.moquillon@gmail.com
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<laurent.laffont@gmail.com>
| To: "Seaside - developer list"<seaside-dev@lists.**squeakfoundation.org<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 <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.
2011/8/8 laurent laffont <laurent.laffont@gmail.com>
It seems chrooting each account is not so easy.
I had a chrooted seaside instance running some time ago. I wrote about it on my now abandoned blog, but you can find the contents still here: http://web.archive.org/web/20090331220201/http://blog.blobworks.com/2008/12/... This might be of help if you still want to setup a chroot environment, but I guess this still falls into the category of "not so easy". :-] Alex
laurent are you doing that in a clone of the git vm because it would be good for traceability? Stef On Aug 8, 2011, at 10:09 AM, laurent laffont wrote:
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 <miguel.moquillon@gmail.com> 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> | 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.
On Mon, Aug 8, 2011 at 1:11 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
laurent
are you doing that in a clone of the git vm because it would be good for traceability?
We will. Laurent.
Stef
On Aug 8, 2011, at 10:09 AM, laurent laffont wrote:
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 < miguel.moquillon@gmail.com> 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> | 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.
On Mon, Aug 8, 2011 at 1:11 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
laurent
are you doing that in a clone of the git vm because it would be good for traceability?
the repository is here: https://gitorious.org/~laurentlaffont/cogvm/smallharbour Laurent.
Stef
On Aug 8, 2011, at 10:09 AM, laurent laffont wrote:
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 < miguel.moquillon@gmail.com> 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> | 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.
Hi. with a public SmallHarbour (public fork of SeasideHosting - smallharbour.org)
people can upload images that do bad things: change filesystem, run commands, ....
, users, services... I don't know about freebsd, but I hear about jails and its advantages over chroot. http://www.freebsd.org/doc/handbook/jails-intro.html 2011/8/8 Miguel Moquillon <miguel.moquillon@gmail.com>
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> | 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.
On 6 August 2011 12:06, laurent laffont <laurent.laffont@gmail.com> wrote:
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, ?)
you don't need to remove dangerous plugins. What you can do (with latest VMs) is to use 'disable module loading' mechanism. http://code.google.com/p/cog/issues/detail?id=13
Can we easily chroot ? what are known solutions ? Laurent.
-- Best regards, Igor Stasenko AKA sig.
participants (8)
-
Alexander LazareviÄ -
Dale Henrichs -
Diogenes Moreira -
Gastón Dall' Oglio -
Igor Stasenko -
laurent laffont -
Miguel Moquillon -
Stéphane Ducasse