2008/11/30 John M McIntosh <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
