Plash: tools for practical least privilege

2007/02/26: There is now a wiki for Plash: Documentation from this site is being gradually moved there.

Plash is a system for sandboxing GNU/Linux programs. Plash's aim is to protect you from the programs you run by letting you run them with the minimum authority and privileges they need do do their job -- this is the Principle of Least Authority (POLA). Plash can run programs in a secure, restricted execution environment with access to a limited subset of your files.

Plash can be used to run servers, command line tools, and applications with graphical user interfaces:

  • Applications with graphical interfaces: You can dynamically grant GUI applications access rights to individual files that you want to open or edit. This happens transparently through the Open/Save file chooser dialog box. Plash replaces Gtk's GtkFileChooserDialog so that the file chooser is implemented outside the application in a separate process, as a trusted component. This file chooser is known as a powerbox, because it delegates additional power to the application. See examples and screenshots.
  • Servers: You can run a network-accessible server with minimal access rights so that if it is compromised (e.g. via a buffer overrun bug), the adversary cannot compromise the whole machine. Or you can set up an HTTP or FTP server with a limited view of the filesystem to export handpicked files without having to rely on the server's application-level access control mechanisms. See examples.
  • Command line tools: Using Plash, you can run tools with read-only access to their inputs and write access to their outputs. Sandboxes are lightweight, so you can, for example, create a sandbox for running gcc to compile a single file. See examples.

Plash virtualizes the file namespace, and provides per-process/per-sandbox namespaces. Plash grants access to files by mapping them into otherwise empty namespaces. This allows for fine-grained control over dependencies: You can link a program with specific versions of dynamic libraries by mapping individual files; or you can just map the whole /usr directory into the program's namespace.

Plash provides two main interfaces for granting access rights to sandboxed processes:

  • The pola-run tool: This is a command line interface for launching programs to run inside a sandbox. Its arguments let you grant the sandboxed program access to files and directories. pola-run can be used from within a sandbox, allowing nested sandboxes.
  • The powerbox: This is a GUI that works transparently -- it adds a security role to a dialog box that normal users already use for choosing files. Users therefore do not have to adjust much. However, applications or their libraries must be changed to make requests via the powerbox component.

pola-shell is another way to launch sandboxed programs. It is a shell with syntax similar to the Bourne shell or Bash. It lacks many scripting features so is intended for interactive use only.

How it works: virtualizing the file namespace

Plash's sandboxing mechanism works on unmodified Linux kernels (2.6, 2.4 and earlier) and can run normal Linux executables, provided they are dynamically linked.

Sandboxed processes do not use the kernel's filename-based system calls, such as "open". Plash effectively disables these system calls by putting the sandboxed process in a very minimal chroot() jail. (It also gives the sandboxed process a unique, dynamically-allocated UID and GID.)

Instead, a sandboxed process accesses the filesystem by making remote procedure calls (RPCs) across a socket to a server process. To open a file, the sandboxed process sends an "open" request containing the filename. The server process can send a file descriptor for a file across the socket in response.

Plash dynamically links sandboxed programs with a modified version of GNU libc (glibc), which replaces the filename-related calls (such as open()) so that they make RPCs across the socket instead of using the usual system calls. (See the table of glibc calls to see which functions are affected.)

In most cases this does not seriously affect performance because the most frequently called system calls, such as read() and write(), are not affected. Once a sandboxed program has opened a file and obtained a file descriptor for it, there is no further mediation by the server process, and it can use the normal system calls on the file descriptor.

See the architecture section for more details.

Mailing list

There is a mailing list for Plash, for announcements and general discussion. You can subscribe through the mailing list page, or by e-mailing with "subscribe" in the subject line.

Another way to be notified of new releases is to subscribe to the project on its Freshmeat page.

Related systems

Plash is strongly influenced by systems that use capability-based security. Plash itself uses a capability architecture, and the idea of a powerbox user interface comes from the same tradition.

There are two other existing systems that implement file powerboxes:

  • CapDesk, a desktop GUI which is based around the E programming language. E is implemented in Java, and CapDesk uses a Java-based widget set to provide its GUI. Programs must be written in E specially to run under CapDesk.
  • Polaris, a system for sandboxing Windows applications, such as Word and Internet Explorer. Polaris is proprietary software. See the tech report on Polaris.

The powerbox concept appears to have first been proposed by Ka-Ping Yee and Miriam Walker in Interaction Design for End User Security (December 2000).

Plash has been influenced by the EROS operating system, a research system which is now being developed under the name CapROS. EROS is based on KeyKOS, which was proprietary. A successor to EROS is being designed, called Coyotos. Like EROS, Coyotos will be free software.


These additions are planned for the future:

  • Python bindings for the Plash object system. This will be more flexible than pola-run for setting up execution environments for programs. This would let you implement Plash objects in Python. For example, you could create a directory object whose contents listing is chosen dynamically by Python code. You could implement executable objects in Python.

  • Persistence: Implement a simple persistent store, allowing capabilities to be saved, such as capabilities for file and directory objects and executable objects.

    Having persistence means that an application's installation endowment (eg. its executable, libraries and configuration files) can be saved as object references in the persistent store, rather than listed on the command line in a script that invokes pola-run. When installing an application, it can be granted access to necessary files and objects using a powerbox.

  • X Window System access control: Initially I plan to write a proxy for the X11 protocol which will isolate an (unmodified) X client from other X clients, with the possible exception of allowing access to the clipboard.

    Later versions could add mechanisms to allow X clients to co-operate securely by sharing X resources; X clients would probably need to be changed to use such mechanisms.

    Ultimately it would be good to get this integrated into the X server, when we figure out what is required.


Plash is free software, distributed under the GNU Lesser General Public Licence.