[Vm-dev] [squeak-dev] File & Socket Handle Access

[David T. Lewis]

On Wed, Aug 16, 2017 at 01:52:12PM +0200, Bert Freudenberg wrote:
>  
> On Wed, Aug 16, 2017 at 1:36 PM, Denis Kudriashov <dionisiydk at gmail.com>
> wrote:
> 
> > Hi Eliot.
> >
> > I asked David why he didn't add it to the SocketPlugin in the first place
> >> and he discussed Andreas Rabb's security concerns
> >
> >
> > It would be interesting to read about them because it looks strange that
> > it is secure to manage OS handle from VM but not secure to manage it from
> > image side. Both ways are requested by user directly or indirectly which
> > means that user has OS permissions. So what the difference?
> >
> 
> ???It's for when yo???u want to allow arbitrary code to be executed in the
> image, yet still protect the machine from harm. This happens when sharing
> objects between images - an object could have malicious code attached. So
> in that case, before running the code, we turn on the VM file sandbox via
> the SecurityPlugin. This ensures that the image can only access files in a
> sandbox directory but not outside. But it only works if the FilePlugin is
> the only way to access files - meaning FFI and OSProcess etc. must be
> disabled, and there must not be another way to create file handles.

Bert's summary sounds right to me.

I also recall a couple of points that Andreas was trying to advance, and after
a good deal of digging through the mail archives I think I found the most
recent that he had suggested:

  http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004106.html

This proposal never got traction, but I think it is still worth our consideration.

So for background for this discussion, I think that there were two proposals
that Andreas provided:

1) The handle registry in the win32 VM support code, which causes FilePlugin
to refuse to operate on handles that were created outside of the plugin
itself (e.g. a handle created by some other plugin, such as OSPP). This is
described in the comment at the head of the source file:

  http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/vm/sqWin32HandleTable.h?revision=1287&view=markup

2) Andreas' later proposal to replace this with a more general facility for
the VM to support a registration mechanism that would provide similar protection,
but that would also make it possible for a handle created by OSPP (such as
a file handle on an OS pipe) to be used by the file plugin.

  http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004106.html

My personal opinion is that #1 is too restrictive and causes more problems
than it solves; and that #2 is more complicated than I might like, but it
does seem workable and might be worth further consideration.

Regardless of my own opinions, I hope that we will read Andreas' proposals
and reconsider them, especially #2 which was a later proposal that potentially
provides a workable balance between security concerns and practical implementation.

> 
> So IMHO, if the goal is to get a raw handle for using in FFI, then that's
> okay, since all security goes out the door as soon as FFI is enabled
> anyway. And if FFI is not enabled, then the raw file handle isn't useful,
> so there is no need to restrict read-access to it. Or am I missing
> something?
> 
> TL;DR read-only access to raw file handle may not be a security issue.

Agreed.

Dave