Sandbox

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Sandbox

Casey Ransberger-2

Hello all, I hope this is the right list for this question.

I want very much to know more about the sandbox functionality in the Squeak VM. Are there any resources out there that can help me understand how this works?

My *real* question was "can this be made to work usefully with the JIT VM?" but I realized that it would be better to ask for pointers about the sandbox and see if I can maybe ask some more informed/specific questions about the JIT and the sandbox later.

I'd rather understand it than get the answer, I guess:)
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox

Igor Stasenko
 
On 2 May 2011 05:15, Casey Ransberger <[hidden email]> wrote:
>
> Hello all, I hope this is the right list for this question.
>
> I want very much to know more about the sandbox functionality in the Squeak VM. Are there any resources out there that can help me understand how this works?
>
> My *real* question was "can this be made to work usefully with the JIT VM?" but I realized that it would be better to ask for pointers about the sandbox and see if I can maybe ask some more informed/specific questions about the JIT and the sandbox later.
>

JIT changes nothing in this regard, since it works seamlessly and
there is no extended functionality which may cause more
security risks comparing to interpreter.

> I'd rather understand it than get the answer, I guess:)

You should start looking at security plugin first.
Not long ago i added an extra primitives to disable the module loading
mechanism for the rest of the session.

So, the scheme how to use it is following:
- at image startup , you forcely loading all modules you may want to
use , by issuing

Smalltalk loadModule: 'moduleName'

per each module you want.

And then immediately after that  you disabling the module loading by issuing:

Smalltalk disableModuleLoading.

In this way, any code in image, which using primitives from modules
which not were loaded before will fail.
This applies not only to external modules, but also to internal ones.
For instance if you not loaded a socket plugin, and disabled module
loading before first use of it, you won't be able to
use it for the rest of the session and therefore you don't need to
care about security issues from that side.

So, in addition to security plugin, which tries to control various
security options for some plugins (like files and sockets),
a new mechanism makes sure that you cannot escape sandboxed mode by
using some untrusted module which could contain a potential
security holes and therefore could compromise a system security.

Here the platform code which enabling new functionality:

https://gitorious.org/cogvm/blessed/commit/ca86f61967a21a9ae13642ad70596451c0f91b61

a corresponding primitives integrated into VMMaker-oscog since
VMMaker-oscog-IgorStasenko.54

--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Sandbox

Igor Stasenko

Also, see
http://code.google.com/p/cog/issues/detail?id=13


On 2 May 2011 11:02, Igor Stasenko <[hidden email]> wrote:

> On 2 May 2011 05:15, Casey Ransberger <[hidden email]> wrote:
>>
>> Hello all, I hope this is the right list for this question.
>>
>> I want very much to know more about the sandbox functionality in the Squeak VM. Are there any resources out there that can help me understand how this works?
>>
>> My *real* question was "can this be made to work usefully with the JIT VM?" but I realized that it would be better to ask for pointers about the sandbox and see if I can maybe ask some more informed/specific questions about the JIT and the sandbox later.
>>
>
> JIT changes nothing in this regard, since it works seamlessly and
> there is no extended functionality which may cause more
> security risks comparing to interpreter.
>
>> I'd rather understand it than get the answer, I guess:)
>
> You should start looking at security plugin first.
> Not long ago i added an extra primitives to disable the module loading
> mechanism for the rest of the session.
>
> So, the scheme how to use it is following:
> - at image startup , you forcely loading all modules you may want to
> use , by issuing
>
> Smalltalk loadModule: 'moduleName'
>
> per each module you want.
>
> And then immediately after that  you disabling the module loading by issuing:
>
> Smalltalk disableModuleLoading.
>
> In this way, any code in image, which using primitives from modules
> which not were loaded before will fail.
> This applies not only to external modules, but also to internal ones.
> For instance if you not loaded a socket plugin, and disabled module
> loading before first use of it, you won't be able to
> use it for the rest of the session and therefore you don't need to
> care about security issues from that side.
>
> So, in addition to security plugin, which tries to control various
> security options for some plugins (like files and sockets),
> a new mechanism makes sure that you cannot escape sandboxed mode by
> using some untrusted module which could contain a potential
> security holes and therefore could compromise a system security.
>
> Here the platform code which enabling new functionality:
>
> https://gitorious.org/cogvm/blessed/commit/ca86f61967a21a9ae13642ad70596451c0f91b61
>
> a corresponding primitives integrated into VMMaker-oscog since
> VMMaker-oscog-IgorStasenko.54
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.