August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Web app security

by GastÃ³n Dall' Oglio

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(a)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(a)gmail.com> >> | To: "Seaside - developer list"<seaside-dev(a)lists.squeakfoundation.org>, >> "An open mailing list to discuss any topics >> | related to an open-source Smalltalk"< >> pharo-project(a)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. >> >> > >

Aug. 8, 2011

[Pharo-project] Be careful, problem with WeakOrderedCollection in Pharo (there is a fix)

by Mariano Martinez Peck

Hi Chris. We found a problem with WeakOrderedCollection in Pharo which may cause problems in Magma users in Pharo. Basically, once a WeakOrderedCollection needed to #grew, it stops being weak because the internal array was replaced by a Array instead of a WeakArray. (WeakOrderedCollection new instVarNamed: 'array') class ->>>> WeakArray (WeakOrderedCollection new grow instVarNamed: 'array') class ->>>> Array So....I can imagine that some applications running magma may grow a lot due to this bug. Just to check whether someone is having this bug or not, you may want to execute: WeakOrderedCollection allInstances select: [:each | (each instVarNamed: 'array') class = Array ] if you have instances, then that's a problem ;) To fix it, you can fileine the changes of the issue tracker: http://code.google.com/p/pharo/issues/detail?id=4596 and then you should fix the already created instances. cheers ps: I have no idea how much Magma uses WeakOrderedCollection, but I thought it was just worth it to raise a warning. -- Mariano http://marianopeck.wordpress.com

Aug. 8, 2011

Re: [Pharo-project] Web app security

by laurent laffont

On Mon, Aug 8, 2011 at 1:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)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(a)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(a)gmail.com> > > | To: "Seaside - developer list"<seaside-dev(a)lists.squeakfoundation.org>, > "An open mailing list to discuss any topics > > | related to an open-source Smalltalk"< > pharo-project(a)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. > > > > > > > > > > >

Aug. 8, 2011

Re: [Pharo-project] Growl in Pharo

by StÃ©phane Ducasse

sorry the alpha vanishing color of the handle :) On Aug 8, 2011, at 10:31 AM, Tudor Girba wrote: > > On 8 Aug 2011, at 09:15, StÃ©phane Ducasse wrote: > >> >> On Aug 7, 2011, at 11:45 PM, Tudor Girba wrote: >> >>> Thanks, Stef. >>> >>> This is cool. I will use it in Glamour :) >> >> feel free to add more classVariable as custom hooks. >> I will check the alp with igor. > > What is alp? > > Doru > > > >> >>> >>> Cheers, >>> Doru >>> >>> >>> On 7 Aug 2011, at 19:10, StÃ©phane Ducasse wrote: >>> >>>> Hi >>>> >>>> I was brainstorming for an example to illustrate announcements and I wanted to have a Growl feature. >>>> So I looked at Snarl from Tony Garnock-Jones and I redesigned a simpler Morph. >>>> >>>> It could be more generic with better default handled default. >>>> I do not understand why the color of the text is ignored but I can not want to spend more time on it now. >>>> Apparently the first time the text is read and when the background or the color of the border are set the blue get propagated. :( >>>> >>>> GrowlMorph openWithLabel: 'The time' contents: (TimeStamp now)) >>>> >>>> If somebody would like to glue together Growl and the available announcements it would be fun to check. >>>> >>>> Gofer new >>>> squeaksource: 'Growl'; >>>> package: 'Growl'; >>>> load >>>> >>>> GrowlMorph openWithLabel: 'The time' contents: (TimeStamp now) >>>> >>>> Stef >>>> >>>> Something changed between 14042 and 14077 because I do not have the same alpha for the handle but I do not have the time to check. >>>> I do not understand why round corners are not taken into account. >>>> >>>> >>>> >>>> >>>> <Screen shot 2011-08-07 at 6.55.07 PM.pdf><Screen shot 2011-08-07 at 6.56.40 PM.pdf> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "We can create beautiful models in a vacuum. >>> But, to get them effective we have to deal with the inconvenience of reality." >>> >>> >> >> > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > >

Aug. 8, 2011

Re: [Pharo-project] Web app security

by StÃ©phane Ducasse

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(a)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(a)gmail.com> > | To: "Seaside - developer list"<seaside-dev(a)lists.squeakfoundation.org>, "An open mailing list to discuss any topics > | related to an open-source Smalltalk"<pharo-project(a)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. > > > >

Aug. 8, 2011

Re: [Pharo-project] Releasing 1.3: TODOs

by StÃ©phane Ducasse

On Aug 8, 2011, at 1:06 PM, laurent laffont wrote: > On Mon, Aug 8, 2011 at 10:48 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 8, 2011, at 10:39 AM, Tudor Girba wrote: > > > Great! As soon as you release 1.3, we will release Moose 4.6 based on it, so I hope it will be soon :) > > > It will be this week... maybe tomorrow? I only need to figure out the VM story... > > +1 for an official VM release. I rarely know which one to use, I often fall back on Eliot's builds. +1 Use ours :) They are on the jenkins servers. Stef > > >> > >> > >> For 1.4, we should *really* *really* make sure that we auto-generate the *final* *unchanged* release artefact... > >> and *one* *defined* family of VMs, with the one-click (and just one one-click, not two) build from the latest VM. > >> > >> Marcus > >> > >> -- > >> Marcus Denker -- http://marcusdenker.de > >> > >> > > > > -- > > www.tudorgirba.com > > > > "No matter how many recipes we know, we still value a chef." > > > > > > > > > > > > > > > > -- > Marcus Denker -- http://marcusdenker.de > > >

Aug. 8, 2011

Re: [Pharo-project] Releasing 1.3: TODOs

by laurent laffont

On Mon, Aug 8, 2011 at 10:48 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Aug 8, 2011, at 10:39 AM, Tudor Girba wrote: > > > Great! As soon as you release 1.3, we will release Moose 4.6 based on it, > so I hope it will be soon :) > > > It will be this week... maybe tomorrow? I only need to figure out the VM > story... > +1 for an official VM release. I rarely know which one to use, I often fall back on Eliot's builds. Laurent. Marcus > > > > Cheers, > > Doru > > > > > > On 8 Aug 2011, at 08:51, Marcus Denker wrote: > > > >> TODOs to get 1.3 released: > >> > >> 1) store a 1.3Core on gforge build with an old vm. Double check it works > with old VM. > >> > >> It is likely that, again, I did not think about this for some of the > images on gforge... it might > >> mean that we need to re-generate images and re-build the Full image > based on that. > >> I should again stress that this situation is sucking the live out of > people (at least me) and > >> we need to *simplify* our story *considerably*. This is *not* > sustainable like this. > >> > >> 2) store a 1.3 on gforge (take form Hudson). double check with old vm > >> > >> 3) update the one-click with reasonable Vms. Which ones? I am confused > wrt to VMs, so I need help here. > >> > >> 4) update the website. > >> - especially regarding VMs > >> > >> > >> For 1.4, we should *really* *really* make sure that we auto-generate the > *final* *unchanged* release artefact... > >> and *one* *defined* family of VMs, with the one-click (and just one > one-click, not two) build from the latest VM. > >> > >> Marcus > >> > >> -- > >> Marcus Denker -- http://marcusdenker.de > >> > >> > > > > -- > > www.tudorgirba.com > > > > "No matter how many recipes we know, we still value a chef." > > > > > > > > > > > > > > > > -- > Marcus Denker -- http://marcusdenker.de > > >

Aug. 8, 2011

Re: [Pharo-project] UTF-8 support when exporting to XML

by StÃ©phane Ducasse

Hilaire we will start to write a chapter on string encoding with henrik and I would like to have an example on XML could you send me the snippet of code that saved you :) Tx On Aug 5, 2011, at 5:23 PM, Hilaire Fernandes wrote: > So far it was an orthogonal problem to XML Parser. > > I have to submit to XMLWriter a stream with UTF8 converter. > > StandardFileStream does not handle it, but MultiByteFileStream does. > > Thanks Henrik. It avoids me to check with latest XMLParser. > > Hilaire > > Le 05/08/2011 13:21, Hilaire Fernandes a Ã©crit : >> Hello, >> >> I am wondering, does latest XML Parser get the string value really >> exported to UTF-8. >> I am still using an old version #20 of XMLParser (for code >> compatibility) and I noted that Pharo accented string (still in 8 bits >> forms as far as I can see) are not converted to UTF-8 when exported in >> the XML file. >> >> Is it still the case with latest XML Parser? >> >> Hilaire >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

Aug. 8, 2011

Re: [Pharo-project] Writing an object graph into a no-sql database [WAS] Re: [Seaside] ESUG SummerTalk - Fuel, binary object serializer

by GÃ¶ran Krampe

On 08/07/2011 04:00 PM, Mariano Martinez Peck wrote: > Thanks guys for all you answers. I am taking them into account. A few remarks: - If you want "just add another box" for true master less scalability and fault tolerance (same k/v pairs stored at say 3 machines in parallell), then Riak is an incredibly cool and nice db right now. And while it can use JSON values it is not tied to it. - If you want crazy speed on a single box then you can use Tokyo Tyrant (or its newer cousin, don't recall its name). I wrote a binary binding for it a while back and it is an insanely fast k/v store. - CouchDB is also nice but IMHO Riak is more interesting at this time. regards, GÃ¶ran

Aug. 8, 2011

Re: [Pharo-project] Web app security

by Alexander LazareviÄ

2011/8/8 laurent laffont <laurent.laffont(a)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

Aug. 8, 2011