Status: FixToInclude
Owner:
[hidden email]
Labels: Milestone-1.3
New issue 3859 by
[hidden email]: Pluggin control
http://code.google.com/p/pharo/issues/detail?id=3859Hello,
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.
Attachments:
SmalltalkImage-loadModule.st 424 bytes
SmalltalkImage-disableModuleLoading.st 460 bytes
Locked
