November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FFI inside Pharo ?

by Marcus Denker

On 29.11.2008, at 19:41, John M McIntosh wrote: > > On 29-Nov-08, at 1:14 AM, Marcus Denker wrote: > >> >> On 28.11.2008, at 12:35, Antony Blakey wrote: >> >>> >>> On 28/11/2008, at 9:43 PM, Damien Cassou wrote: >>> >>>> On Fri, Nov 28, 2008 at 12:07 PM, Igor Stasenko >>>> <siguctua(a)gmail.com> wrote: >>>>> May i guess, that dev image should contain FFI package by default? >>> >>> Has there been any discussion about using Alien exclusively as a >>> Pharo goal? >> >> >> No discussion really, but I think this would be nice. >> >> I personally think that a good FFI is base fuctionality, e.g. it >> allows to >> move glue-code into the image that normally would be in primitives. >> >> Now Alien does only support intel... so it's not there yet, even >> though there >> has been lots of progress (very nice!). > > > Er so what else is missing, I do hope to complete the powerpc work > this week. > Very cool! So we could use it as the one and only standard FFI. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 30, 2008

Re: [Pharo-project] Re: FileList2 merged with FileList

by StÃ©phane Ducasse

hi hernan thanks for your contribution. Could you sign the license agreement and send it to me :) Stef On Nov 29, 2008, at 11:44 PM, HernÃ¡n Morales Durand wrote: > I forgot to mention, to install it: > > -Remove the Morphic-FileList category. > -Evaluate: > > FileStream fileIn: 'Morphic-FileList.st'. > FileStream fileIn: 'FileListNewReferences.st' > > 2008/11/29 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > Issue 269: http://code.google.com/p/pharo/issues/detail?id=269&q=FileList2&colspec=ID%… > > Attachements: > Morphic-FileList.st contains FileList merged from old FileList and > FileList2 > Removed FileList2 references in FileListNewReferences.st > > Two issues: > -It is possible to establish a preference for saving a method > without modification of the authorship/annotation information ? > -Why methods have authors but classes don't ? > > Cheers > > HernÃ¡n > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 30, 2008

Re: [Pharo-project] New pharo-dev based on 10178

by StÃ©phane Ducasse

I would really like to make the halos menu only showing up when we press shift and this for all the system. The halso are cool for mroph and duplicating window for example but they get in our way. Stef >>> > We should remove this second world-menu. > >> The "other" world menu has an item "show main docking bar (M)", >> turning it on results in a walkback: >> >> AnObsoleteBlueSmallLandColorTheme>>dockingBarColor should have >> been implemented. > > Here is a fix. > > <DockingbarFix.cs> > > > But the docking-bar needs some work in general... lots of things are > accessible in the menues that should > be removed. > >> >> >> The window look (Watery2) is quite slick ... so very non-squeaky :-) > > :-) > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 30, 2008

Re: [Pharo-project] FFI inside Pharo ?

by Igor Stasenko

and besides: VMs is packaged with FFI as dynamic library. So, if you want extra safety - simply don't shipp your application with this DLL. But still, if you allow arbitrary code to run in your image, then what prevents script kiddie from doing following: - hiddenly download a SqueakFFIPrims.dll (which is 30720 bytes long. i doubt that anyone will notice it) - hiddenly file-in a .cs which contains FFI classes - start exploiting your OS/VM whatever As an extreme variant, one can do following: HackyClass>>pluginBinaryFile ^ #( .... contents of binary file ) (FileStream forceNewFileNamed: 'MyPlugin.dll') nextPutAll: HackyClass pluginBinaryFile. now, all i left to do is to call primitive: HackyClass>>doNastyThings <primitive: 'nasty' module: 'MyPlugin.dll'> does this example makes any difference now, whether you have FFI or not? :) -- Best regards, Igor Stasenko AKA sig.

Nov. 30, 2008

Re: [Pharo-project] FFI inside Pharo ?

by Igor Stasenko

2008/11/30 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Ah well security. > > So the view is it would be nice to have Alien/FFI in the image & VM so you > can execute any operating system API you've rights to execute. > This enables folks to write smalltalk code and exploit operating system > features without having to rely on the difficult procedure of creating a > plugin and setting up a platform > development environment. It also provides for better support since changes > can be done by someone submitting a fix to MC somewhere, versus relying on a > handful of > people who do the plugin development. I personally think this is a good > idea if I ignore everything written below. > > Now once you allow the loading of arbitrary, non-signed, mystery code from > the internet you have the following: > > (a) well obviously a script has full user read/write access to the file > systems & network just using native squeak. The squeak sandboxing attempts > to limit that > but can be defeated and in my audit of the squeak platform api's it's > obvious most platforms consider primitive callers to be friendly and not > attempt nasty things like buffer overflows or do other devious things. No > doubt any serious effort at exploitation would defeat the current > sandboxing. > > (b) Enabling FFI then allows the script to do lots more, likely also > exploit privilege escalation exploits etc, run arbitrary binaries etc. Which > is the > problem Michael refers to. > > > I'm not about to go anywhere near proposing any solutions since this entire > topic has had billions of $ spent on solving it. > Let's make it clear: a) we do want FFI for developers b) we don't want to run arbitrary unsecure code in deployed images to make (a) we should include FFI into image/vm to make (b) its a developers who should care and make own security measures to prevent loading/executing unwanted/unsecure code. If you leave the doors open - script kiddie can crash your VM or break image to unusable state. I don't think that at this point it makes a real difference whether FFI installed or not. If we don't have a ways how to make a safe sandboxing at language level, then its pointless to make VM care of that, because VM can't really tell which code is safe to run and which is not - its plainly interpreting what you giving to it :) > > On 29-Nov-08, at 12:06 PM, StÃ©phane Ducasse wrote: > >> Mike >> >> could you explain a bit more the scenario. >> would the people have to add a dll? >> >> Stef >> >> On Nov 29, 2008, at 10:25 AM, Michael Rueger wrote: >> >>> Marcus Denker wrote: >>>> >>>> I personally think that a good FFI is base fuctionality, e.g. it allows >>>> to >>>> move glue-code into the image that normally would be in primitives. >>> >>> The problem with FFI (and Alien) is that by using FFI and thus having the >>> FFI plugin installed you completely circumvent any security you gain from >>> the sandbox. >>> This is only really interesting for an environment like etoys where you >>> allow arbitrary scripts to be loaded. Right now we are not supporting etoys, >>> but the question is what, down the road, is going to happen. >>> >>> Another question is how more use of FFI opens us up to issues other >>> languages have. So far Smalltalk wasn't hackable (on the server), with FFI >>> generally available it could be? >>> >>> If people vote this a non-issue I'm fine with it, but I wanted at least >>> to raise the issue at hand. >>> >>> Michael > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 30, 2008

Re: [Pharo-project] FFI inside Pharo ?

by Antony Blakey

On 30/11/2008, at 12:04 PM, John M McIntosh wrote: > Now once you allow the loading of arbitrary, non-signed, mystery > code from the internet you have the following: But why do that? And why compromise Pharo simply so that people can do that? Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 One should respect public opinion insofar as is necessary to avoid starvation and keep out of prison, but anything that goes beyond this is voluntary submission to an unnecessary tyranny. -- Bertrand Russell

Nov. 30, 2008

Re: [Pharo-project] FFI inside Pharo ?

by John M McIntosh

Ah well security. So the view is it would be nice to have Alien/FFI in the image & VM so you can execute any operating system API you've rights to execute. This enables folks to write smalltalk code and exploit operating system features without having to rely on the difficult procedure of creating a plugin and setting up a platform development environment. It also provides for better support since changes can be done by someone submitting a fix to MC somewhere, versus relying on a handful of people who do the plugin development. I personally think this is a good idea if I ignore everything written below. Now once you allow the loading of arbitrary, non-signed, mystery code from the internet you have the following: (a) well obviously a script has full user read/write access to the file systems & network just using native squeak. The squeak sandboxing attempts to limit that but can be defeated and in my audit of the squeak platform api's it's obvious most platforms consider primitive callers to be friendly and not attempt nasty things like buffer overflows or do other devious things. No doubt any serious effort at exploitation would defeat the current sandboxing. (b) Enabling FFI then allows the script to do lots more, likely also exploit privilege escalation exploits etc, run arbitrary binaries etc. Which is the problem Michael refers to. I'm not about to go anywhere near proposing any solutions since this entire topic has had billions of $ spent on solving it. On 29-Nov-08, at 12:06 PM, StÃ©phane Ducasse wrote: > Mike > > could you explain a bit more the scenario. > would the people have to add a dll? > > Stef > > On Nov 29, 2008, at 10:25 AM, Michael Rueger wrote: > >> Marcus Denker wrote: >>> I personally think that a good FFI is base fuctionality, e.g. it >>> allows to >>> move glue-code into the image that normally would be in primitives. >> >> The problem with FFI (and Alien) is that by using FFI and thus >> having the FFI plugin installed you completely circumvent any >> security you gain from the sandbox. >> This is only really interesting for an environment like etoys where >> you allow arbitrary scripts to be loaded. Right now we are not >> supporting etoys, but the question is what, down the road, is going >> to happen. >> >> Another question is how more use of FFI opens us up to issues other >> languages have. So far Smalltalk wasn't hackable (on the server), >> with FFI generally available it could be? >> >> If people vote this a non-issue I'm fine with it, but I wanted at >> least to raise the issue at hand. >> >> Michael -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 30, 2008

[Pharo-project] Re: FileList2 merged with FileList

by HernÃ¡n Morales Durand

I forgot to mention, to install it: -Remove the Morphic-FileList category. -Evaluate: FileStream fileIn: 'Morphic-FileList.st'. FileStream fileIn: 'FileListNewReferences.st' 2008/11/29 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > Issue 269: > http://code.google.com/p/pharo/issues/detail?id=269&q=FileList2&colspec=ID%… > > Attachements: > Morphic-FileList.st contains FileList merged from old FileList and > FileList2 > Removed FileList2 references in FileListNewReferences.st > > Two issues: > -It is possible to establish a preference for saving a method without > modification of the authorship/annotation information ? > -Why methods have authors but classes don't ? > > Cheers > > HernÃ¡n > >

Nov. 29, 2008

[Pharo-project] FileList2 merged with FileList

by HernÃ¡n Morales Durand

Issue 269: http://code.google.com/p/pharo/issues/detail?id=269&q=FileList2&colspec=ID%… Attachements: Morphic-FileList.st contains FileList merged from old FileList and FileList2 Removed FileList2 references in FileListNewReferences.st Two issues: -It is possible to establish a preference for saving a method without modification of the authorship/annotation information ? -Why methods have authors but classes don't ? Cheers HernÃ¡n

Nov. 29, 2008

Re: [Pharo-project] New pharo-dev based on 10178

by Marcus Denker

On 27.11.2008, at 19:42, Stefan Schmiedl wrote: > On Thu, 27 Nov 2008 17:48:33 +0100 > "Damien Cassou" <damien.cassou(a)gmail.com> wrote: > >> https://gforge.inria.fr/frs/download.php/11845/pharo0.1-10178dev08.11.7.zip >> > > downloaded, started and performed my usual "stress test" > (what happens when I click there?). > > There are two "World" menus: the one coming up on left click on > background > and the "other" one coming up on middle/right click depending on > mouse settings. > We should remove this second world-menu. > The "other" world menu has an item "show main docking bar (M)", > turning it on results in a walkback: > > AnObsoleteBlueSmallLandColorTheme>>dockingBarColor should have > been implemented. Here is a fix. But the docking-bar needs some work in general... lots of things are accessible in the menues that should be removed. > > > The window look (Watery2) is quite slick ... so very non-squeaky :-) :-) -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 29, 2008