Skip to content

Audit the containerisation code #6

@tomsmeding

Description

@tomsmeding

The worker currently uses bubblewrap (using linux cgroups) for privilege separation, and systemd-run (using linux user namespaces) for limiting of volatile resources (time, memory). While this is a nice, lightweight setup, it's not an existing setup, and it has not been audited.

If anyone has the expertise to have an informed opinion about these kind of systems, please help!

The system is as follows: (all is in the play-haskell-worker/ directory)

  • The bwrap-files/ubuntu-base directory is a chroot populated with an Ubuntu installation, set up in the chroot target of Makefile using bwrap-files/chroot-initialise.sh. Hopefully the precise workings of this step do not actually matter for the security property below.
  • The worker starts bwrap-files/stage-1.sh with one argument: a file descriptor that is open for writing in the stage-1.sh process (say P).
  • The worker sends a bunch of untrusted bytes on stdin of P.
  • The worker expects a bunch of untrusted bytes on stdout and stderr of P, as well as on the pipe of which one end is that writable file descriptor.
  • The worker kills the container.

Assuming that the worker (and the server and the client webpage after that) handle the output bytes safely, the security property is (loosely formulated) that no matter what bytes are sent to P, the outside of the container is not harmfully affected. That is to say: the container does not perform network activity, puts no lasting data on disk, and maybe other things that I haven't thought of.

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions