How to create headless VM without some primitives?

 
Hi,

I'd like to create a headless VM without some primitives. I want a VM
without file support and without FFI support (for example). The idea is to
be able to run the image in a kind of sandboxed environment without the risk
of reaching (at least some of) the OS from code. The only interface should
probably be the network.

How would I go about creating such a VM? Should I 'simply' use the existing
VM build scripts and configure it such that no unwanted primitives are
compiled? Or do I need to change the VM-Maker? Any pointers are welcome!

Thx for any advice!

Regards,
Erik




--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 


> On 2020-04-13, at 1:06 PM, Erik Stel <[hidden email]> wrote:
> I'd like to create a headless VM without some primitives.


> How would I go about creating such a VM?

You *should* be able to simply remove the unwanted plugins from the plugins.int/ext files that specify what gets built and whether they are compiled as internal or external plugins. That of course assumes you want to drop entire plugins, which sounds likely.

The disadvantage is that anyone with access could simply stick a copy of the relevant plugin in the relevant place and it would get loaded...

Have you tried looking at the SecurityPlugin and how it is used? That is/was an attempt to handle this sort of case. Browse the class 'SecurityManager'.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Kdatlyno does it take to change a lightbulb?”
"None. It sounds perfectly OK to them."

 
Hi Tim,

Thanks for the quick reply. The first solution sounds very doable. I'm not
sure if file access would really be a problem (if one has reached that level
of access, there are other things to worry about ;-). It is supposed to be
used in a cloud environment.

The SecurityPlugin is new to me. I'll have a look at it too!

Cheers,
Erik




--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 
A couple of other points that might be worth discussing for this sort of usage

a) it's way past time we stopped opening a windows when it isn't needed. No window should be created until and unless the system actually writes to the display and calls for a display update. This would enable image-controlled headlessness. RISC OS was able to cope with it 25 years ago.

b) containers. At least, so far as the currently very limited understanding of containers that I have suggests. AIUI you can make a bundle that behaves as a (nearly) separate machine and do permissions stuff to sandbox it. I'm having a bit of a hard time making much detail sense of it but I'm sure someone hereabouts can explain if in words of one syllable or less.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The halfway point between right and wrong is still damn wrong. Compromise isn't always a solution

 
Hi Tim,

a) Indeed this could be something for the VM to decide. When 'deploying' the
VM I would like it to be as small as possible as well. So if leaving out
(unnecessary) code is possible, I'm happy to do that. Although I'm not
planning to wrangle out every little byte to safe space.

b) True as well. But that would probably also prevent the VM itself to
read/write to the filesystem which is not what I want. I might (at some
point) include a plugin which does some very specific file I/O. At least for
logging purposes. But this is not decided yet.

I'll have a go with compiling the VM without specific plugins and have a
look at the SecurityManager.

Cheers,
Erik
 



--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 
Hi Erik,

As Tim says, eliminating plugins from plugins.int/plugins.ext, except MiscPrimitivePlugin and the math plugins, is one thing to do.  Another is to use the build.minheadless build to produce a truly headless vm that has no platform support for the GUI.

 


> On 2020-04-13, at 10:45 PM, Erik Stel <[hidden email]> wrote:
>
> a) Indeed this could be something for the VM to decide. When 'deploying' the
> VM I would like it to be as small as possible as well. So if leaving out
> (unnecessary) code is possible, I'm happy to do that. Although I'm not
> planning to wrangle out every little byte to safe space.

It probably isn't worth putting much effort into saving space on the VM code since it is what, 1-2MB? Compare that to a likely 50-100MB for an image with Seaside etc. In the far distant past we used to have to worry about out image sizes but these days they're not really much bigger than the other kind of image that our cellphone cameras produce!

>
> b) True as well. But that would probably also prevent the VM itself to
> read/write to the filesystem which is not what I want. I might (at some
> point) include a plugin which does some very specific file I/O. At least for
> logging purposes. But this is not decided yet.

I'm really not up to speed with containers stuff but I'm pretty sure you can configure being able to write to (some) parts of the filing system of your choice.  Anyone out there with better knowledge of this stuff should please chime in, pointers to *good* explanations, tutorials, manuals, doc all appreciated. Googling gets far too much dross these days unless you already know a fair bit.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Original Sin is hard to find, but the digitally enhanced version is readily available.

 
Tim,

I agree, the effort to save bytes should not be too high.

If someone has some input/experience on using container technology to
limit/sandbox the environment I'm happy to hear about it. Using the
'default' headless VM would be very beneficial wrt not having to maintain
and build custom VM's.

A bit off topic, but I'm starting with a tiny image because of my use case:
I'm actually starting with a very small image. Currently I have an image of
150Kb which has basic classes (*) to gets things going and a WebSocket
class. Another Smalltalk image can send messages to the tiny image to get
performed and the tiny can send events back. With this mechanism additional
classes and methods are installed. Depending on what is installed the image
can stay relative small. The tiny image is based on PharoCandle (see
https://github.com/carolahp/PharoCandleSrc). The image currently runs inside
a browser using SqueakJS (and thereby becomes a Javascript-engine
replacement) or it runs as a NodeJS application. Pretty experimental still.
I would like to use this same image as the base for the cloud instances. And
probably use it for running on Raspberry Pi's as well (for users which do
not have or want to use the cloud). IF experiments do work out as currently
'planned' ;-).

(*) Strings, Numbers, Collections, Process stuff (i.e. no compiler, methods
are installed using bytecode)

Regards,
Erik




--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 
This is interesting to me, both the minimal image and running in
SqueakJS (how's that?) and loading ProCrypto-1-1-1 and ThunkStack and
ParrotTalk, for now. I am currently consumed inside my port of SSL over
to ThunkStack. I would love to have a link to your minimal image. Is it
possible?

Kindly,
Robert

On 4/14/20 3:32 PM, Erik Stel wrote:
--
Kindly,
Robert

 
Robert,

I'm open sourcing everything. I hope to publish first version in coming
weeks. Expect it to be somewhat volatile ;-).

Cheers,
Erik



--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 
Excellent, don't go until you are ready. I will keep my eye out for your
announcement.

K, r

On 4/15/20 1:36 AM, Erik Stel wrote:
--
Kindly,
Robert

 
Basic api for squeak vm from a decade ago found here https://isqueak.org/PlatformVMAPI
On Tue, Apr 14, 2020 at 22:36, Erik Stel <[hidden email]> wrote:

Robert,

I'm open sourcing everything. I hope to publish first version in coming
weeks. Expect it to be somewhat volatile ;-).

Cheers,
Erik



--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 
On Tue, Apr 14, 2020 at 02:32:18PM -0500, Erik Stel wrote:
> If someone has some input/experience on using container technology to
> limit/sandbox the environment I'm happy to hear about it. Using the
> 'default' headless VM would be very beneficial wrt not having to maintain
> and build custom VM's.

The simplest is to run the VM with a dedicated non-root UID within the
container, and configure the in-container filesystem permissions to
allow said UID to write only to specific directories.

My Dockerfile:

  FROM samadhiweb/pharovm:49c2617-alpine
  RUN addgroup -g 1099 pharoapp \
    && adduser -D -u 1099 -G pharoapp -h /home/pharoapp pharoapp
  WORKDIR /pkg/image
  COPY app.image app.image
  RUN chown -R pharoapp:pharoapp /pkg/image
  EXPOSE 8081
  ENV LD_LIBRARY_PATH /pkg/vm
  USER pharoapp:pharoapp
  CMD /bin/runapp.sh

Pierce

 
Hi Pierce,

Thx for the reply and the dockerfile.

This would limit the ability to write, but you can't prohibit reading the
filesystem I think. The VM needs to read the image for one thing. If the VM
would allow FFI or OSProcess, would it be possible to limit application
execution using container configuration? Because with FFI/OSProcess a
(naughty) user could try to gain access to applications or data.

Cheers,
Erik



--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 
On Fri, Apr 17, 2020 at 01:11:54AM -0500, Erik Stel wrote:
> This would limit the ability to write, but you can't prohibit reading the
> filesystem I think. The VM needs to read the image for one thing. If the VM
> would allow FFI or OSProcess, would it be possible to limit application
> execution using container configuration? Because with FFI/OSProcess a
> (naughty) user could try to gain access to applications or data.

Hi Erik,

My VM is built on Alpine Linux. The official Alpine Linux Docker image
is about 5MB. Adding the VM and plugins (including my own custom
libsqlite3.so and some other shared libraries) gives a Docker image
under 20MB. The size of your application - Smalltalk image, changes if
required, other artefacts - is in your control of course.

While running the application using a non-root dedicated UID does not
prohibit the VM from reading the filesystem (assuming your code allows
it), using Alpine Linux means there is very little in the filesystem to
be read at all.

See https://www.samadhiweb.com/tags/Alpine%20Linux for some blog posts.
Github here: https://github.com/pharo-contributions/Docker-Alpine

It should be possible to implement more stringent controls using Linux
filesystem ACLs or Docker configuration.

HTH.

Pierce

 
Thx I'll have a look.



--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 


Any pointers you can offer to a decent 'Dummies guide to Docker and containers' would be appreciated. I need the an equivalent to 'See container. See container run. Run, container, run!' sort of intro.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The severity of the itch is proportional to the reach.

 
On Sun, Apr 19, 2020 at 10:53:46AM -0700, tim Rowledge wrote:
> Any pointers you can offer to a decent 'Dummies guide to Docker and
> containers' would be appreciated. I need the an equivalent to 'See
> container. See container run. Run, container, run!' sort of intro.

Hi Tim,

Take a look at the links here: http://wiki.astares.com/pharo/612

Pierce

 

 
On Wed, Apr 29, 2020 at 13:57, Ben Coman <[hidden email]> wrote:

On Tue, 14 Apr 2020 at 10:43, tim Rowledge <[hidden email]> wrote:

 
a) it's way past time we stopped opening a windows when it isn't needed. No window should be created until and unless the system actually writes to the display and calls for a display update. This would enable image-controlled headlessness. RISC OS was able to cope with it 25 years ago.

Pharo is doing that, in their branch https://github.com/pharo-project/opensmalltalk-vm/tree/headless

which IIUC is the branch being used to build all Pharo VM going forward.   Once they've worked the bugs out of it,

it might be worth pulling that back to evaluate for Squeak to use.

cheers -ben