On 21 March 2011 11:54, Bert Freudenberg <[email protected]> wrote: > > On 21.03.2011, at 03:12, Igor Stasenko wrote: > >> On 21 March 2011 02:43, Levente Uzonyi <[email protected]> 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.
