Sandboxing for containers
Even when user namespaces are fully implemented, there remains the concern that containers share an OS with the host, and may be able to exploit syscall vulnerabilities (in particular) to gain access to and privilege in the host.
Historically, relatively new syscalls in particular, have ended up with vulnerabilities which a container would be able to exploit.
It would be nice if we could deny a container from using certain system calls, perhaps by a method analogous to seccomp. http://
This blueprint, then, is for following, helping and testing, or initiating the seccomp+ftrace approach.
Blueprint information
- Status:
- Complete
- Approver:
- Dave Walker
- Priority:
- High
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Serge Hallyn
- Definition:
- Approved
- Series goal:
- Accepted for precise
- Implementation:
-
Implemented
- Milestone target:
-
ubuntu-12.04
- Started by
- Robbie Williamson
- Completed by
- Robbie Williamson
Whiteboard
Status: not yet started
The seccomp2 patch in the oneiric kernel supports execve, but is not yet upstream. There is a minijail0 POC general sandbox tool which works on precise and could be packaged. LXC support for seccomp2 should be possible.
Work Items:
[jjohansen] Get seccomp2 into ubuntu kernel or ppa for testing: DONE
[serge-hallyn] First review of new approach: DONE
[serge-hallyn] Lkml review of new approach: DONE
[serge-hallyn] Package minijail0: POSTPONED
[serge-hallyn] Send POC of lxc integration to lxc-dev: POSTPONED
[serge-hallyn] Write testcases for lxc seccomp2 integration: POSTPONED
Comments:
A patch with a new approach is being worked on. As such, the
previously planned work items do not make sense for this cycle
and have been marked POSTPONED.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
