- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs

by Igor Stasenko

On 21 March 2011 13:03, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > On 21.03.2011, at 12:42, Igor Stasenko wrote: > >> On 21 March 2011 11:54, Bert Freudenberg <bert(a)freudenbergs.de> wrote: >>> >>> On 21.03.2011, at 03:12, Igor Stasenko wrote: >>> >>>> On 21 March 2011 02:43, Levente Uzonyi <leves(a)elte.hu> wrote: >>>>> On Sun, 20 Mar 2011, Igor Stasenko wrote: >>>>> >>>>>> Hello, >>>>>> i just wanna to inform you that i adopted NativeBoost plugin for >>>>>> building with latest Cog vms. >>>>> >>>>> Great. >>>>> >>>>>> >>>>>> To build VM, you should have an image with VMMaker + CMakeVMMaker >>>>>> packages installed. >>>>>> >>>>>> Then load NBIntaller package and do: >>>>>> NBInstaller installCogPlugin >>>>>> >>>>>> There are new cmake configurations i added to build VMs with NB plugin >>>>>> support. >>>>> >>>>> It's an old question, but I don't remember your answer, so: wouldn't it >>>>> be better to add a command line switch for enabling NB? So even if a VM is >>>>> compiled with NB, I can still turn it off if I want to. >>>>> >>>> >>>> It is disabled by default, when you starting a new image. >>>> This allows me to not care if some of the methods were carrying native >>>> code saved into an image. >>>> >>>> For enabling a native code, one should invoke #primitiveEnable first. >>>> You can customize a mechanism of enabling it in >>>> NativeBoost class>>enableNativeCode >>>> and put checking of command-line argument(s) there. >>>> >>>> And yes, i am against putting extra logic at plugin side :) >>>> The reason is simple: if you using it, then you know what you doing, >>>> and if you don't - then you safe anyways. >>> >>> IMHO it's a good idea to not allow native code execution if the VM sandbox is enabled. Just like e.g. OSProcess checks the SecurityPlugin for this. >>> >> >> Bert, but you cannot state that your deployment are more secure just >> because you are passing "right" command-line arguments to VM. > > I didn't say anything about command line arguments. > >> As i said before , if you want security for real, then you should >> build own "sandboxed" version of VM, which simply having no way to use >> such features. > > I disagree. There should be a single version of the VM that can be used in almost all circumstances. E.g. there should be a single Linux package for the VM. Possibly three for interpreter/stack/cog, but it makes no sense at all to have more than one interpreter, IMHO. > It sounds as contradiction to me. From one side you want to make VM being responsible for certain level of security, but from another side, you want it to be open for "insecure" stuff like NativeBoost. Apparently you can't have both at once. You should choose one. Unless you change VM to disable external module loading mechanism, there is no any security guarantees, only imaginable ones. I could download plugin from web, place it into 'secure' directory and then tell VM to load it as external plugin. And where is your command-line option(s) now? For things like NativeBoost, it is responsibility of developer(s) , what level of security is desirable/enough for them. In this regard, VM is just a tool which developers using. And may i ask, why you don't want to put a security measures at language side? You can disable or completely remove compiler. You can disable a primitives which allow doing "nasty" stuff, and of course you can make it controllable from command line. And because it is at language side, it is much easier to maintain and fix and develop in general. So, why not? I am really enjoying that smalltalk has a wide open architecture, but at the same time it missing one simple thing: a 'deployment' mode, where you have certain security guarantees out of the box. So that's an open question, why we never had that in Squeak.. VM cannot do such magic, it is too stupid and cannot really tell if given sequence of bytecodes/class format/external plugin are secure enough or not. This logic is best to be put at image side where you can reason about it much easier because you have reflection ( and smalltalk instead of C :) > It would be a shame if e.g. Etoys would have to ship its own VM because you made it less secure in newer versions. After all, it was Etoys that convinced all the major Linux distros to even include a VM. > No no no.. Please stop looking at VM as a black-box with two inputs and one TV output. This approach is too naive and will never pass any real-world testing, moreover it hinders any progress towards improving state of art. If you approach with our "standard" VM to some serious guys, first thing they will do is to ask a security expert to evaluate it.. And then any your proposal which is based on such technology will be rejected instantly, and i fear that project budget will be spent on making same thing but in java. So, it is a shame that we don't have a good answer to tough guys, and instead of really looking how to make system sound and secure, we're like sitting ducks with all these command-line options, which can be cracked by some clever guy in few minutes. In my vision, VM should be made a dynamically loadable library with nice API to interact with host application. Currently we have a monolithic VM, which is host and library in one. But in future i'd like (and not just me btw) to have VM which can be easily embedded into a host application, and then host application can control security as well as many other aspects. For things like browser plugin, you simply can't use same things for everything. And so, we should provide a way for making it easy to customize VM for own purpose(s), but at same time make it flexible enough to make forking pointless. And that's exactly why we building an infrastructure for VMs: it will enable us to build own custom VMs in much easier, much less painful and much more controllable way. And for Etoys this is a way to go: you can share the same code base, but in own corner you could have mods, which will disable or stub-out unwanted/insecure functionality. In that way you can be confident that application you distributing is secure, and instead of arguing with me (or some other VM developer guy) what is best for you, you can do it yourself without much stress. :) Just don't tell me that you don't want this, or you never considered it as a good perspective. ( I won't believe you anyways ;) >> Otherwise that's just a painting on the water pool. > > I don't quite get that analogy ;) > Standing on the bank of river and trying to paint on water stream. > And we're not after absolute security, which can't be achieved anyway. But why taking a step back from where we are already? > > - Bert - > -- Best regards, Igor Stasenko AKA sig.

March 21, 2011

[Pharo-project] Thank you ProfStef

by Max Leske

Just a short thank you Stef. When I thought about tackling Metacello configurations it felt like it was going to be tough. But then: ProfStef to the rescue! Really a great idea! How many other IDE's sport a tutorial mechanism that can be easily extended by anyone? Not many I guess... Cheers, Max

March 21, 2011

Re: [Pharo-project] test crashing the cog vm

by Toon Verwaest

I couldn't agree more! However, here the problem is not that the format isn't a correct format. The problem is that a bytecode is activated that is incompatible with the instance format. So basically on every bytecode accessing an instance you would have to check if this is a valid access. And as we all know, Smalltalk avoids this; it makes things faster :) Toon On 03/21/2011 12:49 PM, Igor Stasenko wrote: > On 21 March 2011 11:29, Tudor Girba<tudor.girba(a)gmail.com> wrote: >> Thanks, Toon! >> >> I changed the code to explicitly set the format, and it seems to fix the problem: >> >> cls := Class new superclass: MooseElement; >> setFormat: MooseElement format; >> yourself. >> cls compileSilently: 'mooseName ^ 1/0'. >> element := cls new. >> >> Is this correct? >> > Yes, you should pay attention to have correct format. > But of course VM could also be more cautios and verify if your class > are well formed before creating an instance of it.. > > > >> Cheers, >> Doru >> > >

March 21, 2011

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs

by Bert Freudenberg

On 21.03.2011, at 12:42, Igor Stasenko wrote: > On 21 March 2011 11:54, Bert Freudenberg <bert(a)freudenbergs.de> wrote: >> >> On 21.03.2011, at 03:12, Igor Stasenko wrote: >> >>> On 21 March 2011 02:43, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> On Sun, 20 Mar 2011, Igor Stasenko wrote: >>>> >>>>> Hello, >>>>> i just wanna to inform you that i adopted NativeBoost plugin for >>>>> building with latest Cog vms. >>>> >>>> Great. >>>> >>>>> >>>>> To build VM, you should have an image with VMMaker + CMakeVMMaker >>>>> packages installed. >>>>> >>>>> Then load NBIntaller package and do: >>>>> NBInstaller installCogPlugin >>>>> >>>>> There are new cmake configurations i added to build VMs with NB plugin >>>>> support. >>>> >>>> It's an old question, but I don't remember your answer, so: wouldn't it >>>> be better to add a command line switch for enabling NB? So even if a VM is >>>> compiled with NB, I can still turn it off if I want to. >>>> >>> >>> It is disabled by default, when you starting a new image. >>> This allows me to not care if some of the methods were carrying native >>> code saved into an image. >>> >>> For enabling a native code, one should invoke #primitiveEnable first. >>> You can customize a mechanism of enabling it in >>> NativeBoost class>>enableNativeCode >>> and put checking of command-line argument(s) there. >>> >>> And yes, i am against putting extra logic at plugin side :) >>> The reason is simple: if you using it, then you know what you doing, >>> and if you don't - then you safe anyways. >> >> IMHO it's a good idea to not allow native code execution if the VM sandbox is enabled. Just like e.g. OSProcess checks the SecurityPlugin for this. >> > > Bert, but you cannot state that your deployment are more secure just > because you are passing "right" command-line arguments to VM. I didn't say anything about command line arguments. > As i said before , if you want security for real, then you should > build own "sandboxed" version of VM, which simply having no way to use > such features. I disagree. There should be a single version of the VM that can be used in almost all circumstances. E.g. there should be a single Linux package for the VM. Possibly three for interpreter/stack/cog, but it makes no sense at all to have more than one interpreter, IMHO. It would be a shame if e.g. Etoys would have to ship its own VM because you made it less secure in newer versions. After all, it was Etoys that convinced all the major Linux distros to even include a VM. > Otherwise that's just a painting on the water pool. I don't quite get that analogy ;) And we're not after absolute security, which can't be achieved anyway. But why taking a step back from where we are already? - Bert -

March 21, 2011

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

by Bert Freudenberg

On 21.03.2011, at 12:40, Marcus Denker wrote: > > On Mar 21, 2011, at 12:23 PM, Sven Van Caekenberghe wrote: > >> >> On 21 Mar 2011, at 11:20, Bert Freudenberg wrote: >> >>> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad. >> >> Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone. >> However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that. >> >> Your other points a valid, of course. >> >> > I think that "security" was not meant in the sense of accidentally loading wrong code. More in the sense that one could just > delete all your code. Even though we have backups of the SqueakSource filesystem, you don't want that, as it would be a > mess to repair. > > Marcus IIRC SqueakSource keeps the old version as a separate file when "overwriting", so nothing is really lost. It's cumbersome to restore though indeed. - Bert -

March 21, 2011

Re: [Pharo-project] test crashing the cog vm

by Igor Stasenko

On 21 March 2011 11:29, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Thanks, Toon! > > I changed the code to explicitly set the format, and it seems to fix the problem: > > Â Â Â Â cls := Class new superclass: MooseElement; > Â Â Â Â Â Â Â Â setFormat: MooseElement format; > Â Â Â Â Â Â Â Â yourself. > Â Â Â Â cls compileSilently: 'mooseName Â ^ 1/0'. > Â Â Â Â element := cls new. > > Is this correct? > Yes, you should pay attention to have correct format. But of course VM could also be more cautios and verify if your class are well formed before creating an instance of it.. > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig.

March 21, 2011

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs

by Igor Stasenko

On 21 March 2011 11:54, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > On 21.03.2011, at 03:12, Igor Stasenko wrote: > >> On 21 March 2011 02:43, Levente Uzonyi <leves(a)elte.hu> wrote: >>> On Sun, 20 Mar 2011, Igor Stasenko wrote: >>> >>>> Hello, >>>> i just wanna to inform you that i adopted NativeBoost plugin for >>>> building with latest Cog vms. >>> >>> Great. >>> >>>> >>>> To build VM, you should have an image with VMMaker + CMakeVMMaker >>>> packages installed. >>>> >>>> Then load NBIntaller package and do: >>>> NBInstaller installCogPlugin >>>> >>>> There are new cmake configurations i added to build VMs with NB plugin >>>> support. >>> >>> It's an old question, but I don't remember your answer, so: wouldn't it >>> be better to add a command line switch for enabling NB? So even if a VM is >>> compiled with NB, I can still turn it off if I want to. >>> >> >> It is disabled by default, when you starting a new image. >> This allows me to not care if some of the methods were carrying native >> code saved into an image. >> >> For enabling a native code, one should invoke #primitiveEnable first. >> You can customize a mechanism of enabling it in >> NativeBoost class>>enableNativeCode >> and put checking of command-line argument(s) there. >> >> And yes, i am against putting extra logic at plugin side :) >> The reason is simple: if you using it, then you know what you doing, >> and if you don't - then you safe anyways. > > IMHO it's a good idea to not allow native code execution if the VM sandbox is enabled. Just like e.g. OSProcess checks the SecurityPlugin for this. > Bert, but you cannot state that your deployment are more secure just because you are passing "right" command-line arguments to VM. As i said before , if you want security for real, then you should build own "sandboxed" version of VM, which simply having no way to use such features. Otherwise that's just a painting on the water pool. > - Bert - > -- Best regards, Igor Stasenko AKA sig.

March 21, 2011

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

by Marcus Denker

On Mar 21, 2011, at 12:23 PM, Sven Van Caekenberghe wrote: > > On 21 Mar 2011, at 11:20, Bert Freudenberg wrote: > >> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad. > > Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone. > However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that. > > Your other points a valid, of course. > > I think that "security" was not meant in the sense of accidentally loading wrong code. More in the sense that one could just delete all your code. Even though we have backups of the SqueakSource filesystem, you don't want that, as it would be a mess to repair. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2011

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

by Sven Van Caekenberghe

On 21 Mar 2011, at 11:20, Bert Freudenberg wrote: > SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad. Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone. However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that. Your other points a valid, of course. Sven

March 21, 2011

Re: [Pharo-project] allOverriddenMethods is confusing

by Cyrille Delaunay

I think that this part of RPackage has just been copied from PackageInfo to work quickly with monticello. So for now RPackage deal with overriden methods in the same way than PackageInfo 2011/3/21 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > On Mar 20, 2011, at 9:48 31AM, StÃ©phane Ducasse wrote: > > > So allOverriddenMethods returns all the methods of the complete system > and it may be correct but strange to have it on the instance side. > Probably for convenience, so you don't write self class allIOverriden... in > methods like the one below. > > > Now my hypothesis is that > > > > > >> overriddenMethodsDo: aBlock > > "Enumerates the methods the receiver contains which have been > overridden by other packages" > > ^ self allOverriddenMethodsDo: [:ea | > > (self isOverrideOfYourMethod: ea) > > ifTrue: [aBlock value: ea]] > > > > check the complete system for every package snapshot and since we have a > lot of override because of polymorph we pay the price. > > I will fold the overrides first and try to understand mc > > > > > > Stef > > Yes, allOverridenMethods returns all overrides in the entire system. > Another example of what you have to do when using categories for packaging > :) > > To figure out the overridden methods in your package, it > - Checks class category is not yours > - Scans source for old category. > > Since .changes has been trunkated since Polymorph was merged, you won't > find any packages whose methods are actually overridden by the Polymorph > overrides :P > > Cheers, > Henry > > PS. How does RPackage deal with overriden methods? > PPS. I profiled this long ago, while it did show up, removing overrides > didn't actually have a noticeable impact on the loading speed of Monticello >

March 21, 2011