[Pharo-project] FFI inside Pharo ?
On Fri, Nov 28, 2008 at 12:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
May i guess, that dev image should contain FFI package by default?
What do other people think? -- Damien Cassou http://damiencassou.seasidehosting.st
On 28/11/2008, at 9:43 PM, Damien Cassou wrote:
On Fri, Nov 28, 2008 at 12:07 PM, Igor Stasenko <siguctua@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? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 75% of statistics are made up on the spot.
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@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!). So one idea could be to have both for now... and replace the old as soon as Alien is ready. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
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
2008/11/29 Michael Rueger <m.rueger@acm.org>:
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
I suggested it only for dev images. A basic image may not have FFI. But then it shouldn't contain any package which using FFI (like freetype glue-code).
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
+1 On Nov 29, 2008, at 3:14 AM, Marcus Denker <denker@iam.unibe.ch> 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@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!).
So one idea could be to have both for now... and replace the old as soon as Alien is ready.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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. -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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
2008/11/30 John M McIntosh <johnmci@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@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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.
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@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@iam.unibe.ch http://www.iam.unibe.ch/~denker
Hi, I think we should have FFI in the base-image. Not using a very good FFI to make talking to the outside world would be a mistake. The Outside, where *everthing* is happening... just look at how the libraries of MacOS progressed in the last 10 years compared to Squeak... Security... hard problem. We should solve it on a different level. Marcus On 30.11.2008, at 02:34, John M McIntosh wrote:
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@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Igor Stasenko wrote:
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:
the sandbox does that as it prevents writing of files in "interesting" locations like the VM directory. I'm all for using FFI/Alien, what I really tried to make people aware of is that by using FFI instead of plugins certain things become more dangerous. For standalone and server applications not loading any code from the outside this is not a problem at all. By using FFI we need to more aware though that we potentially open up a Squeak application to buffer overflow attacks, something that wasn't really possible before. So I didn't want to put any brakes on, but raise people's awareness about security. It's a bit like with the Mac: just because hackers haven't really cared about exploiting vulnerabilities doesn't mean the Mac is safe. And we Smalltalkers have considered us to use the Mac of programming languages and thus feeling safe for the longest time ;-) Michael
2008/11/30 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
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:
the sandbox does that as it prevents writing of files in "interesting" locations like the VM directory.
what if i put .dll in directory which is included in a search path? There can be many indirect ways to leave something on disk, and then run it by OS. Not sure about macs, but on windows, a good sandboxing would be to prevent any file i/o. But then if you running a seaside (or any mid-sized app), i'm sure you will need file i/o for yourself .
I'm all for using FFI/Alien, what I really tried to make people aware of is that by using FFI instead of plugins certain things become more dangerous. For standalone and server applications not loading any code from the outside this is not a problem at all.
By using FFI we need to more aware though that we potentially open up a Squeak application to buffer overflow attacks, something that wasn't really possible before.
So I didn't want to put any brakes on, but raise people's awareness about security. It's a bit like with the Mac: just because hackers haven't really cared about exploiting vulnerabilities doesn't mean the Mac is safe. And we Smalltalkers have considered us to use the Mac of programming languages and thus feeling safe for the longest time ;-)
First, i should care about safety & stability of my own deployed application, then about possible exploits of different backends, such an OS or dynamic libraries. If i leave security responsibility on VM, then i can't guarantee the stability of my own application , and its makes no much sense talking, what exploits attacker could use through FFI interface or whatever, because first thing which under attack is my own application and its data. Would it make anyone happy, if hacker be able to destroy your image, destroy your app data etc etc, but unable to crack operating system?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Thanks! On Nov 30, 2008, at 1:54 PM, Michael Rueger wrote:
Igor Stasenko wrote:
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:
the sandbox does that as it prevents writing of files in "interesting" locations like the VM directory.
I'm all for using FFI/Alien, what I really tried to make people aware of is that by using FFI instead of plugins certain things become more dangerous. For standalone and server applications not loading any code from the outside this is not a problem at all.
By using FFI we need to more aware though that we potentially open up a Squeak application to buffer overflow attacks, something that wasn't really possible before.
So I didn't want to put any brakes on, but raise people's awareness about security. It's a bit like with the Mac: just because hackers haven't really cared about exploiting vulnerabilities doesn't mean the Mac is safe. And we Smalltalkers have considered us to use the Mac of programming languages and thus feeling safe for the longest time ;-)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Antony Blakey -
Damien Cassou -
David Pennell -
Igor Stasenko -
John M McIntosh -
Marcus Denker -
Michael Rueger -
Stéphane Ducasse