Possible use for application sandboxing with containers
This session is to discuss how we could use containers to make the Ubuntu desktop safer for everyone when running untrusted software.
At last UDS in Orlando we discussed about potential use for containers with regular desktop application.
The main use for them in that case is to allow users to run "untrusted" software on their machine and minimize the potential risks of damage caused by the application.
Based on some hacking I did during last UDS, I now have an upstream project called arkose which ships in 11.04 with:
- arkose: Command line tool to start containers (create temporary file system, setup aufs, create the new namespace, ...)
- arkose-gui: A GUI similar to Gnome's run dialog but starting everything in containers (and showing all the possible options)
- arkose-nautilus: A nautilus plugin adding a menu entry for all executable files starting arkose-gui with the right parameters
Arkose only implements what I consider the minimal set of options for desktop app containers which is:
- Network as an option (off by default)
- Everything is copy-on-write (using aufs)
- Direct read/write access for specific directories like /tmp and /home (off by default)
- Space usage limitation
The idea was not to re-invent the wheel and let LXC deal with the most complex container use cases (with a potential port of arkose to LXC if we need more feature).
Desktop app containers could be really handy to try out or even run "extra" apps and thereby reducing the validation process for extras.ubuntu.com.
Another potential use case is to extend the container to contains all the libraries an app might need and so have a container that can be run on any Ubuntu system (useful for proprietary apps using older libraries).
The approach above certainly has a few known issues, especially for GUI application as arkose doesn't do any kind of X11 filtering thereby allowing any contained app to eavesdrop and grab information from the X server. A potential workaround for this would be to add Xephyr as an option to arkose.
Blueprint information
- Status:
- Complete
- Approver:
- Steve Langasek
- Priority:
- Low
- Drafter:
- Stéphane Graber
- Direction:
- Approved
- Assignee:
- Stéphane Graber
- Definition:
- Approved
- Series goal:
- Accepted for oneiric
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Colin Watson
- Completed by
- Stéphane Graber
Whiteboard
Work items:
[alecu] volunteered to write some d-bus aware modules for games: TODO
[stgraber] switch Arkose to using LXC instead of its own containing code: DONE
[stgraber] Implement some kind of X containing (Xephyr ?) into arkose: DONE
[stgraber] Investigate potential configuration file to indicate that a package (ARB?) must run in a container and see if it's possible to have one such package on extras.ubuntu.com for testing: DONE
[stgraber] Work on a proof of concept for contained console and GUI apps (example packages in a PPA): DONE
[stgraber] Discuss at next ARB meeting, chose to wait for 12.04: DONE
== Goal of the session: ==
* Find more use cases for Sandboxing so that it's not just another cool little tool that no one knows about
== Introduction ==
* Sandboxing uses LXC-like containers with cgroups to sanbox applications so that they are less capable of causing any damage to the system
* One use case is packages for extras.ubuntu.com
* GUI tool is similar to gnome-run dialog, networking support for app can also be disabled, supports union/aufs mounts to ramfs or a temporary directory to avoid damage to home directory
* Few lines of C that basically uses kernel namespaces to isolate a program
== Security discussion ==
* Apps can still access X and catch screenshots, keystrokes or do other harmful stuff
* Running it under zephyr would fix this
* Also an X server proxy that filters potentially harmful things
* X security extension sucks, it's incomplete, it casues crashes
* Potential new way to handle X isolation would be to create a system that acts as an X server, but directly proxies (with filtering) to the existing server. nothing exists to do this currently, though.
* root in a container is still dangerous, for example, a root user could load arbitrary modules and basically do anything they want to the host
* even capabilities limitations are still flawed: http://
* sandboxed applications can hold filesystem references that could result in DoS on the host
* Look at chromium security / sandboxing bugs, there are interesting problems that have (partial) solutions that may be useful for the sandboxing tool
* For the future sandboxing environements, switch from direct namespace calls to just generating an LXC configuration
* We never claim sandboxing is completely safe, but it could potentially reduce the risk and additionally, create new security risks (at least as it is right now)
* Why not apparmor instead of Arkose/sandboxing? It can't provide a different network stack, or make process information unviewable to other users, there is some overlap between containers and apparmor, but they are complimentary
* What about d-bus? D-bus doesn't work in containers, so programs like terminator fails in containers, d-bus would need to be implemented somehow
* Apps are usually bad at specifying what they require in terms of networking and other capabilities (ie, "This application needs to access your {address books, networking, home directory, etc}
* A prompt could ask a user to grant access once an app requires certain access
* Currently extras.ubuntu.com apps require security reviews by the ARB before being accepted
* (check if I got it right here) Google app engine gains some security by 'compiling' apps at installation time, which goes some way towards securing some python code amongst other things
== Use cases ==
* Running untrusted software in a contained environment
* Limiting what guest users can do on a system
* Some similar applications might want to access the same kind of data, for example a photo app or a slideshow app might require access to just the Pictures directory, access to only single directories could be allowed for cases like this
== Possible future features ==
* Flag in .desktop files that would make the launcher run the app in a sandbox if set and if sandboxing is available
* Switch Arkose to use LXC since new features are maintained there
* Running some old (or weird apps) for forward-porting old software that require old or otherwise unavailable libraries (ex: SAP gui)
