plash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark Seaborn
Subject: [Plash] Fwd: [sandbox] Plash experiences in Zero Install
Date: Thu, 24 Dec 2009 12:14:27 +0000 (GMT)

-------- Original Message --------
Subject: [sandbox] Plash experiences in Zero Install
From: Thomas Leonard <address@hidden>
To: Michael Stone <address@hidden>
Cc: address@hidden,
        The Zero Install system <address@hidden>
Date: Tue, 15 Dec 2009 19:55:30 +0000

2009/12/11 Michael Stone <address@hidden>:
> Thomas,
>
> Thanks for joining the sandboxing-talk@ mailing list. Is there any
> 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,


-- 
Dr Thomas Leonard               ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
_______________________________________________
Sandboxing-talk mailing list
address@hidden
http://lists.sandboxing.org/listinfo/sandboxing-talk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]