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