On 3/21/2011 16:50, Igor Stasenko wrote:
> On 21 March 2011 15:34, Bert Freudenberg<bert at freudenbergs.de>  wrote:
>> On 21.03.2011, at 14:09, Igor Stasenko wrote:
>>
>>> It sounds as contradiction to me. From one side you want to make VM
>>> being responsible for certain level of security, but from another
>>> side, you want it to be open for "insecure" stuff like NativeBoost.
>>> Apparently you can't have both at once. You should choose one.
>>> Unless you change VM to disable external module loading mechanism,
>>> there is no any security guarantees, only imaginable ones.
>>> I could download plugin from web, place it into 'secure' directory and
>>> then tell VM to load it as external plugin.
>>
>> If the VM sandbox is enabled, file access is restricted to a single directory. So you cannot write the plugin to the plugin directory.
>>
>
> i can hardly imagine a sandbox which allows to write files on file system.
> How much you allowed to write? What if it will just consume all disk space?

Denial of service attacks were never part of the threat model that the 
sandbox is aimed at. FWIW, in the same way you could just hog CPU 
forever. It's possible to do a DOS attack from within the sandbox but 
that's a different threat model than compromising your system.

> But ok. I understand that there are certain security model exists in VM.
> One problem with SecurityPlugin that its not really a plugin but
> instead an integral part of VM, because it is hardwired with many
> other plugins who using it.
>
> I wonder why each of the involved plugins don't implement own,
> in-place security mechanisms instead.

Because the dependencies on things like file access can span plugins. 
For those where it doesn't, one could certainly have an in-place solution.

>> (if there are problems with the current implementation, we should fix those, obviously)
>>
>
> Well, if you can crash VM using simple #become, or infinite
> recursion.. who cares about the rest? :)

Again, crashing ~= compromising. The threat model is very specific: 
Prevent untrusted code from gaining full access to your system. Doesn't 
include protection from crashing. Doesn't include denial of service.

>>>   And where is your command-line option(s) now?
>>
>> This has nothing to do with command line options. The sandbox is enabled by a primitive. Etoys enables it before downloading code. There is no way to disable it once engaged.
>>
>
> How about this:
>   - a single primitive which once activated, freezes the VM's plugin
> set. No new plugins can be loaded/initialized (even internal ones).
>
> Then at startup time, first thing you do is checking if you have all
> plugins you need for your application to work, and for the rest you
> don't care and simply disabling plugin loading mechanism.
> In this way, VM could carry anything, but you have a precise control
> what you want to use.

Yes, this would work for plugins where all-or-nothing is acceptable, 
like NB or FFI.

>> Not if you want to allow the user to write code.
>>
>
> You can control what you compiling. For instance in sandbox mode you
> can simply reject compiling code which having primitive invocations.

It's very difficult to do that. If there was an easy solution to that 
problem, I'd go for it. It would be much advantageous over the security 
plugin but until such a solution exists, the security plugin is a simple 
straightforward way to address the issue.

Cheers,
   - Andreas