1. Introduction
1.1 Who needs that
2. Principles
2.1 Non reversible isolation
2.2 Isolation areas
2.3 New system calls
2.4 Limiting super-user: The capabilities system
2.5 Enhancing the capability system
2.6 Playing with the new system calls
2.6.1 Playing with /usr/sbin/chcontext
2.6.2 Playing with /usr/sbin/chcontext as root
2.6.3 Playing with /usr/sbin/chbind
2.6.4 Playing with /usr/sbin/reducecap
2.7 Unification
3. Applications
3.1 Virtual server
3.2 Per user fire-wall
3.3 Secure server/Intrusion detection
3.4 Fail over servers
4. Installation
4.1 The packages
4.2 Setting a virtual server
4.3 Basic configuration of the virtual server
4.4 Entering the virtual server
4.5 Configuring the services
4.6 Starting/Stopping the virtual server
4.7 Starting/Stopping all the virtual servers
4.8 Restarting a virtual server from inside
4.9 Executing tasks at vserver start/stop time
4.10 Issues
4.11 How real is it ?
5. Features
6. Future directions
6.1 User controlled security box
6.2 Kernel enhancements
6.2.1 Per context disk quota
6.2.2 Global limits
6.2.3 Scheduler
6.2.4 Security issues /dev/random /dev/pts Network devices
7. Alternative technologies
7.1 Virtual machines
7.2 Partitioning
7.3 Limitation of those technologies
8. Conclusion
9. Download
10. References
Top Up

2.4 Limiting super-user: The capabilities system


Once you have created a virtual environment where processes have a limited view of the file-system, can't see processes outside of their world and can only use a single IP number, you still must limit the damages those processes can do. The goal is to run virtual environments and provide some root privileges.

How do you limit those root processes from taking over the system, or even just re-booting it. Enter the capability system. This is not new, but we suspect many people have never heard of it.

In the old Unix/Linux days, user root (user ID 0) could do things other user ID could not. All over the place in the kernel, system calls were denying access to some resources unless the user ID of the process (effective ID in fact) was 0. Plain zero.

The only way a process with user ID 0 could loose some privileges was by changing to another ID. Unfortunately this was an all or nothing deal. Enter the capabilities.

Today, the difference between root and the other users is the capability set. User root has all capabilities and the other users have none. The user ID 0 does not mean anything special anymore. There are around 30 capabilities defined currently. A process may request to loose a capability forever. It won't be able to get it back.

Capabilities allows a root process to diminish its power. This is exactly what we need to create custom super-user. A super-user process in a virtual server would have some privileges such as binding port below 1024, but would not be able to reconfigure the network or reboot the machine. Check the file /usr/include/linux/capability.h to learn which one are available.

Note that the new system calls (new_s_context and set_ipv4root) are not controlled by capabilities. They are by nature irreversible. Once a virtual server is trapped in a chroot/s_context/ipv4root box, it can't escape from the parameters of this trap.

Top Up

One big HTML document