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

6.2.1 Per context disk quota


If one installs virtual servers and grant access to less trusted users, he may want to limit the disk space used. Since a virtual server may create new user accounts and run processes with any user ID it wants, the current kernel disk quota is not powerful enough. First, it can't differentiate between user ID 100 in one virtual server and user ID 100 in another one.

Further, the main administrator may want to control disk space allocated to the virtual server on a server per server basis, unrelated to the various user ID in use in those virtual servers.

The kernel has already user and group disk quota. Adding security context disk quota should be easily done.

To differentiate between user IDs in virtual servers, the kernel could coin together the security context and the user id to create a unique ID. The kernel 2.4 now supports 32 user ID, so combining security context and user ID in a single 32 bits number should be acceptable.

Top Up

One big HTML document