Note that for example SqueakSSL makes a great effort to NOT break the abstraction barriers 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
: in the sense of the SICP, not in the sense of maliciously obstructing.
> On 16.08.2017, at 08:26, Marcel Taeumel <[hidden email]> 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.
>> Am 16.08.2017 02:13:50 schrieb Eliot Miranda <[hidden email]>:
>> 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
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?
2017-08-16 8:40 GMT+02:00 Tobias Pape <[hidden email]>:
In reply to this post by Tobias Pape
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 <[hidden email]>:
It's for when you 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.
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.
- Bert -
2017-08-16 13:52 GMT+02:00 Bert Freudenberg <[hidden email]>:
Thank's Bert. It is clear but I wonder how it can really work. Because if you are able turn on/off VM file sandbox during image runtime then how system prevents arbitrary code to turn off this security back to perform bad actions?
And if it is static setting for whole image session then why it is really useful? OS security solves all these issues.
I ask because I have no idea about SecurityPlugin. So maybe you will point me to some doc.
On Wed, Aug 16, 2017 at 2:13 PM, Denis Kudriashov <[hidden email]> wrote:
It cannot be turned off once the sandbox is enabled. You will have to restart the image.
10 years ago OS security was really bad. Sandboxing applications from each other only just started to become mainstream back then - the OLPC's Sugar OS with Ivan Krstić's "bitfrost" was one of the first, Apple iOS and Android followed, then Mac OS X and Windows. But our VMs still do not use the OS security capabilities - they usually run with the same privileges as the user that is logged in, meaning they can read or even delete all the user's files.
It would be good to make the VM use these modern security features, but I don't know of any plan to do so (maybe apart from the iOS and Android VMs, where the system won't even allow to run an old app).
I don't know of any docs beyond the SecurityManager class, which has some comments in its methods. I guess it could use a nice class comment. But in essence it is very simple - some VM capabilities (namely file access, socket access, and image write) can be disabled, and there is no way of re-enabling them.
- Bert -
In reply to this post by Bert Freudenberg
On Wed, Aug 16, 2017 at 01:52:12PM +0200, Bert Freudenberg wrote:
> On Wed, Aug 16, 2017 at 1:36 PM, Denis Kudriashov <[hidden email]>
> > 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.
|Free forum by Nabble||Edit this page|