[Plash] Fwd: [sandbox] Plash experiences in Zero Install

[Mark Seaborn]

-------- Original Message --------
Subject: [sandbox] Plash experiences in Zero Install
From: Thomas Leonard <***@gmail.com>
To: Michael Stone <***@gmail.com>
Cc: sandboxing-***@lists.sandboxing.org,
The Zero Install system <zero-install-***@lists.sourceforge.net>
Date: Tue, 15 Dec 2009 19:55:30 +0000

Thomas,
chance I could tempt you into saying a few words on the list about how
integrating 0install with plash has worked out for you and for your
users?

Hi Michael,

As you know, Zero Install (http://0install.net) aims to provide
side-effect-free installation which can be used with any available
sandboxing technology. It unpacks each application or library version to
a new unique directory in the cache and then executes the process,
passing in the locations of the selected components (typically by
setting environment variables).

We have tried using Plash in a number of places:

1. When unpacking an archive we used Plash (if available) to ensure the
archive was unpacked to its own directory (to protect us from bugs in
zip, tar, rar, etc). Being able to sandbox this makes it easier to
add support for more formats.

2. When compiling, 0compile (a generic wrapped for other build systems
that first selects and caches build dependencies) can use Plash to
ensure the build process can only write to the target directory.

3. When running, there is a --sandbox option available in the "sandbox"
branch which allows you to specify a custom sandbox. Any required
packages are downloaded and cached first, then the selected versions
are passed as input to the sandbox command. Plash can be used as the
command here (this is not finished).

Plash's command-line interface is easy to use and almost exactly what we
need. However, I'm not actually using it at the moment. The main
problems I experienced were:

- Development is slow and packages often lag behind distribution
releases. For example, there is a package for Ubuntu/Hardy, but not
for the more recent Intrepid, Jaunty and Karmic releases:

http://plash.beasts.org/wiki/DownloadPackages

- In newer distributions, unzip and cpio use fchmod, which isn't
currently supported by Plash. This is why use (1) is no longer
supported:

http://thread.gmane.org/gmane.comp.security.plash/83

- When compiling, the linker tries to link against the Plash version of
the dynamic linker in some cases, which fails:

http://thread.gmane.org/gmane.comp.security.plash/5

This means that 0compile cannot use it for programs with dependencies
that aren't specified explicitly in the link command, so using Plash
while compiling (2) is currently disabled by default.

- Processes running under Plash cannot be killed (because they run as a
different user). Killing the Plash process prevents the sandboxed
process from opening additional files, but it can continue to access
ones it already has open or to consume CPU. This makes (1) somewhat
riskier than it could be, prevents cancelling a build reliably (2) and
prevents killing sandboxed processes (3).

- Plash closes all open file descriptors (except stdin, stdout, and
stderr), which makes it tricky to use with existing applications:

http://thread.gmane.org/gmane.comp.security.plash/121

For example, the --sandbox option above tries to use a pipe to pass
the selected versions to the sandboxed process, but this fails. It is
possible to hack around this (e.g. get Zero Install to pass the FD it
wants to use to the sandbox command and pass an option to Plash to
keep this one open) but these tricks aren't composable.

- Plash doesn't currently support multi-arch (e.g. running x86 binaries
on x64_64):

http://thread.gmane.org/gmane.comp.security.plash/101

In other words, Plash mainly works with existing applications, but not
quite reliably enough that we can have it turned on by default.

I suspect it could be made to work a lot better if Linux provided a
system call (like the proposed seccomp mode 2) to drop most privileges
without needing to switch to another user. That would also make it
possible for non-root users to install it.

Finally, it may also possible to use its path rewriting code for running
applications with hard-coded paths (without using the sandboxing
functions), although this requires writing some Python.

Hope that's of some use,