Ubuntu Wiki

• Launchpad Entry: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-lxc-sandboxing

• Created: May 18, 2011

• Contributors: serge-hallyn, jjohansen

• Packages affected: linux-image, lxc

Summary

The most insurmountable security objection to LXC, so far, has been that containers share a kernel with the host. Therefore most kernel vulnerabilities in the host can be exploited by a container.

seccomp2 has been proposed by the Google chrome team as an extension to seccomp to facilitiate specifying the list of system calls which a process and its children can use. LXC can use this to blacklist new system calls which, historically, will have security vulnerabilities and not be needed by many container workloads.

Seccomp2 will of course also be useful for full workload sandboxing. As such, we would also like to package (or write, should the community not do it) a general wrapper tool for sandboxing untrusted (i.e. downloaded from the net) applications.

Release Note

Ubuntu has extended support for sandboxing untrusted applications. Containers can now be isolated from dangerous and sensitive syscalls.

It is mandatory.

Rationale

User stories

Assumptions

seccomp2 is accepted - or on its way to being accepted - in the upstream kernel.

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

The lxc per-container configuration files will need to support a lxc.syscall type statement for specifying system call black- or whitelists.

Code Changes

Linux kernel will need the seccomp2 patchset, either from upstream or, if it is not yet in Linus' tree, from patchset from the mailing list.

LXC will need code to exploit seccomp2.

A new package would configure seccomp2 before starting a specified (untrusted) program.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec