[Vm-dev] [squeak-dev] File & Socket Handle Access
David T. Lewis
lewis at mail.msen.com
Thu Aug 17 03:45:36 UTC 2017
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>
> > 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:
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:
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.
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
> TL;DR read-only access to raw file handle may not be a security issue.
More information about the Vm-dev