Scripting with Least Privilege


If you are interested in contributing to Shill, please consider one of the following projects. Of course, if you have other ideas, let us know! Please send us an email at if you are interested in contributing.

To help scope potential projects, we have ranked them by anticipated difficulty and time requirements. Projects with one star require minimal programming experience. Projects with two or three stars may require significant experience with systems programming, programming in Racket, or both.

Shill wrappers for common utilities (★)

Many common utilities run with more privileges than they require. An excellent project to familiarize yourself with Shill is to write Shill scripts that wrap common utilities like file(1), cp(1), and ls(1), invoking them with as few capabilities as needed.

Improve Shill documentation (★)

Improvements to Shill's documentation are greatly appreciated. In particular, we need documentation for security contracts and the standard library. Alternatively, you could document your learning experience as a tutorial or getting started guide.

S-Expression syntax (★)

Create an alternative s-expression syntax for Shill.

IDE support (★)

Add support for Shill to an IDE such as Emacs, or Vim. There is already some support for Shill in DrRacket, but a number of additional features could be added such as on-line syntax checking.

Package manager (★★)

Installing packages often requires running scripts that require elevated privileges to install and modify files. A package manager built using Shill would require packages to declare what privileges they require during installation and minimize the risk in running this third-party code.

Trusted libraries for networking (★★)

Using network services like DNS resolution requires powerful capabilities. Writing trusted library functions for these services would allow scripts to access the network with more restricted capabilities.

Daemon manager (★★)

The init system in BSD using scripts to manage long-running services like apache. A new management service could replace these scripts with Shill scripts to make it easy to launch services with minimal privileges.

Add additional primitives to Shill (★★)

Shill has primitives for interacting with the file system but it is still missing many useful primitives for interacting the underlying operating system. This project would require adding additional capabilities for operating system services that are not currently supported by Shill (e.g., sysctl, time management, etc.).

Infer contracts for Shill scripts (★★)

In Shill, every capablity-safe script must come with a contract. A significant burden when writing a Shill script is creating an appropriate contract. However, it is possible to infer a reasonably precise contract from the structure of script itself using techniques similar to type inference.

Port Shill to Linux (★★★)

Shill currently relies on the TrustedMAC mandatory access control framework to implement capability-safe sandboxes. Porting Shill to Linux would require adapting the sandboxing kernel module to use Linux's security framework (LSM).

Support for job control (★★★)

Currently, Shill does not allow scripts to execute binaries in the background. Job control is limited to setting a timeout on executing binaries. Adding job control to Shill will require designing an appropriate capability-based API for managing jobs and modifying the Shill runtime.

Scsh-like syntax for processes (★★★)

The Scsh shell language has special syntax for managing processes, pipes, and I/O redirection. Adding similar syntax to Shill would make launching sandboxed executables easier. Alternatively, consider the syntax used by PLASH, a capability-based interactive shell.

Interactive shell (★★★)

In contrast to most shell scripting languages, Shill is currently lacking an interactive shell. An interactive shell for Shill presents interesting challenges for best presenting information about capabilites and contracts to the user.