On 21.03.2011, at 12:42, Igor Stasenko wrote:

> On 21 March 2011 11:54, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> 
>> On 21.03.2011, at 03:12, Igor Stasenko wrote:
>> 
>>> On 21 March 2011 02:43, Levente Uzonyi <leves at 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 -