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

[Nicolas Cellier]

Sorry to comment without precise knowledge of the exact security
requirements we are after...
... But couldn't these security concerns be addressed by running the
Smalltalk VM in a sandbox VM?
And, even if not as safe as pure virtualization, couldn't a Docker
container offer similar or superior capabilities?

Nicolas

2017-08-16 8:40 GMT+02:00 Tobias Pape <Das.Linux at gmx.de>:

>
> Hi All
>
>
> Note that for example SqueakSSL makes a great effort to NOT break the
> abstraction barriers[1] found in Squeak.
>
> Yes, that makes SqueakSSL a little bit more convoluted than just handing
> over a Socket, but it works with the Way the NetworkPlugin works, and can
> work on any kind of socket…
>
> But seeing that win/linux/mac _all_ "do in" sockets that have fds, it may
> be just practical to go for handing around fds, instead of copying around.
> I don't know about riscos, but Squeak does not run there and does not have
> a SqueakSSL implementation in the first place, currently. (Plan9 should us
> a fd, when supporting).
>
> just my 2ct
>
> Best regards
>         -vacation-tobias
>
>
>
> [1]: in the sense of the SICP, not in the sense of maliciously obstructing.
>
> > On 16.08.2017, at 08:26, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> >
> > Hi Eliot,
> >
> > I don't share the security concerns in this matter, but here are two
> thoughts:
> >
> > 1) The OS handle would just be a number or another simple object? So, I
> would compare it to any other "reference" to an artifact manifested outside
> the image that could become invalid anytime. For example, any URL can be
> stored in-image yet become invalid after some time if the DNS entry would
> vanish.
> >
> > 2) On a conceptual level, I see no issues to mix objects of different
> abstraction levels in the image. We do it all the time. A person might be
> represented as an instance of some Person class that points to an
> SqlDatabase that points to an SqlTable that points to a DirectoryEntryFile
> that points to a FileStream that ... and so on. We would just promote/offer
> the existing abstraction of OS handles to the object-oriented world.
> >
> > It would be unfortunate if security concerns would negatively affect
> consistency in this regard.
> >
> > Best,
> > Marcel
> >> Am 16.08.2017 02:13:50 schrieb 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/572a7df2/attachment-0001.html>