Hello,
just as outcome of previous discussion about security. I think that we missing a mechanism(s) in VM, which will prevent loading new modules into running system, to ensure that no external code could compromise a system security.
In terms of implementation a change is quite simple:
- add a flag into VM's state, named moduleLoadingEnabled - initially this flag should be set to true during system startup - add a primitive which resets this flag
Then modify
ioLoadModule: OfLength: to fail unconditionally if module loading is disabled.
In practice this means that knowing a secure set of modules you are need for your deployment scenario and have them all loaded at startup, you intentionally disabling a module loading mechanism, to prevent any chance to interact with modules which could compromise your security model.
There's also a missing bit in VM api to explicitly load the module with given name. However it is included in IA32ABIPlugin (#primLoadLibrary), but then maybe you don't want to have IA32ABIPlugin at first place, that's why i proposing to promote this primitive to core VM API.
So, by having these bits working, one could implement sandbox mode quite easily, by doing something like following during image startup:
self deployed ifTrue: [ " make sure we loaded modules we will need" #( 'PluginA' 'PluginB' .... 'PluginZ' ) do: [ :each | Smalltalk loadModule: each ].
Smalltalk disableModuleLoading. ].
Then later any code that will try to use plugins, that is not loaded before you disabled module loading mechanism, will simply fail.
This will be good addition to existing security mechanisms.
On 22.03.2011, at 14:10, Igor Stasenko wrote:
Hello,
just as outcome of previous discussion about security. I think that we missing a mechanism(s) in VM, which will prevent loading new modules into running system, to ensure that no external code could compromise a system security.
I like this :)
- Bert -
In terms of implementation a change is quite simple:
- add a flag into VM's state, named moduleLoadingEnabled
- initially this flag should be set to true during system startup
- add a primitive which resets this flag
Then modify
ioLoadModule: OfLength: to fail unconditionally if module loading is disabled.
In practice this means that knowing a secure set of modules you are need for your deployment scenario and have them all loaded at startup, you intentionally disabling a module loading mechanism, to prevent any chance to interact with modules which could compromise your security model.
There's also a missing bit in VM api to explicitly load the module with given name. However it is included in IA32ABIPlugin (#primLoadLibrary), but then maybe you don't want to have IA32ABIPlugin at first place, that's why i proposing to promote this primitive to core VM API.
So, by having these bits working, one could implement sandbox mode quite easily, by doing something like following during image startup:
self deployed ifTrue: [ " make sure we loaded modules we will need" #( 'PluginA' 'PluginB' .... 'PluginZ' ) do: [ :each | Smalltalk loadModule: each ].
Smalltalk disableModuleLoading. ].
Then later any code that will try to use plugins, that is not loaded before you disabled module loading mechanism, will simply fail.
This will be good addition to existing security mechanisms.
-- Best regards, Igor Stasenko AKA sig. <sqNamedPrims.c><StackInterpreterPrimitives-primitiveDisableModuleLoading.st><StackInterpreterPrimitives-primLoadModule.st><SmalltalkImage-loadModule.st><SmalltalkImage-disableModuleLoading.st>
On Tue, Mar 22, 2011 at 04:09:10PM +0100, Bert Freudenberg wrote:
On 22.03.2011, at 14:10, Igor Stasenko wrote:
Hello,
just as outcome of previous discussion about security. I think that we missing a mechanism(s) in VM, which will prevent loading new modules into running system, to ensure that no external code could compromise a system security.
I like this :)
- Bert -
+1
Me too :)
Dave
In terms of implementation a change is quite simple:
- add a flag into VM's state, named moduleLoadingEnabled
- initially this flag should be set to true during system startup
- add a primitive which resets this flag
Then modify
ioLoadModule: OfLength: to fail unconditionally if module loading is disabled.
In practice this means that knowing a secure set of modules you are need for your deployment scenario and have them all loaded at startup, you intentionally disabling a module loading mechanism, to prevent any chance to interact with modules which could compromise your security model.
There's also a missing bit in VM api to explicitly load the module with given name. However it is included in IA32ABIPlugin (#primLoadLibrary), but then maybe you don't want to have IA32ABIPlugin at first place, that's why i proposing to promote this primitive to core VM API.
So, by having these bits working, one could implement sandbox mode quite easily, by doing something like following during image startup:
self deployed ifTrue: [ " make sure we loaded modules we will need" #( 'PluginA' 'PluginB' .... 'PluginZ' ) do: [ :each | Smalltalk loadModule: each ].
Smalltalk disableModuleLoading. ].
Then later any code that will try to use plugins, that is not loaded before you disabled module loading mechanism, will simply fail.
This will be good addition to existing security mechanisms.
-- Best regards, Igor Stasenko AKA sig. <sqNamedPrims.c><StackInterpreterPrimitives-primitiveDisableModuleLoading.st><StackInterpreterPrimitives-primLoadModule.st><SmalltalkImage-loadModule.st><SmalltalkImage-disableModuleLoading.st>
Its integrated into VMMaker-oscog-IgorStasenko.54.mcz
And available in my branch (http://gitorious.org/~abrabapupa/cogvm/sig-cog/commit/ca86f61967a21a9ae13642...)
Hudson already built new VMs with this feature. (Will push it to blessed repository tomorrow).
vm-dev@lists.squeakfoundation.org