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
6.2.4.1 /dev/random
6.2.4.2 /dev/pts
6.2.4.3 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
Prec

2.6.2 Playing with /usr/sbin/chcontext as root

Next

The new_s_context system call has a special semantic for root processes running in security context 0 and having the CAP_SYS_ADMIN capability: They can switch to any context they want.

Normally, new_s_context allocates a new security context by selecting an unused one. It walks all processes and find an ID (an integer) not currently in use.

But root in security context 0 is allowed to select the context it wants. This allow the main server to control the virtual server. The chcontext utility has the --ctx option to specify the context ID you want.

To help manage several virtual server, given that the security context 0 can't see processes in other security context, it is a good thing root in the main server (security context 0) is allowed to select a specific context. Cool. But we also need a way to have a global picture showing all processes in all security context. The security context 1 is reserved for this. Security context 1 is allowed to see all processes on the server but is not allowed to interact with them (kill them).

This special feature was allocated to security context 1 and not 0 (the default when you boot) to isolate virtual servers from the main. This way, while maintaining services on the main server, you won't kill service in vservers accidentally.

Here is an example showing those concepts:


# You must be root, running X
# We start an xterm in another security context
/usr/sbin/chcontext xterm &
# We check, there is no xterm running, yet we can
# see it.
ps ax | grep xterm
# Are we running in security context 0
# We check the s_context line in /proc/self/status
cat /proc/self/status
# Ok we in security context 0
# Try the security context 1
/usr/sbin/chcontext --ctx 1 ps ax | grep xterm
# Ok, we see the xterm, we try to kill it
/usr/sbin/chcontext --ctx 1 killall xterm
# No, security context 1 can see, but can't kill
# let's find out in which security context this
# xterm is running
/usr/sbin/chcontext --ctx 1 ps ax | grep xterm
# Ok, this is PID XX. We need the security context
/usr/sbin/chcontext --ctx 1 cat /proc/XX/status
# We see the s_context, this is SS.
# We want to kill this process
/usr/sbin/chcontext --ctx SS killall xterm

chcontext as root

The /usr/sbin/vpstree and /usr/sbin/vps commands are supplied by the vserver package. They simply runs ps and pstree in security context 1.
Top Up
Prec

Next
One big HTML document