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

[Denis Kudriashov]

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?

2017-08-16 2:13 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

> Hi All,
>
>     recently Denis Kudriashov wanted to access the OS handle of a Socket
> from the image to pass through the FFI.  David Lewis pointed out that the
> AioPlugin provides a primitive to do this.  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 strikes me
> a) that accessing the OS handle of a file or a socket is extremely useful
> in some circumstances and invalid in others
> b) having handle access in a secondary plugin is inconvenient to say the
> least
> c) having access only to Socket handles and not to file handles is also
> inconvenient.
>
> So I propose adding a SecurityPlugin facility to control handle access,
> which would be granted by default, and to add primitives to both the
> SocketPlugin and FilePlugin to answer the native OS handle when the
> SecurityPlugin grants permission.
>
> I also propose adding a compilation flag to the Windows VM to allow
> compiling out Andreas' handle management, which consists merely of
> maintaining a table of the file handles (not the socket handles) that have
> been created by the VM.  It strikes me that a much better solution is
> merely to encrypt the handle via xoring with a value created at random.  I
> don't see how Andreas' solution adds value, especially since it is not
> implemented on other platforms, and merely adds overhead.
>
> Thoughts?  Objections?
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170816/6a0a451f/attachment.html>