We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

03. Existing Infrastructure

Recent Linux Kernels already provide many security features that are utilized by Linux-VServer to do its work. Especially features such as the Linux Capability System, Resource Limits, File Attributes and the Change Root Environment. The following sections will give a short overview about each of these.

03.0. Linux Capability System

In computer science, a capability is a token used by a process to prove that it is allowed to perform an operation on an object. The Linux Capability System is based on "POSIX Capabilities", a somewhat different concept, designed to split up the all powerful root privilege into a set of distinct privileges.

03.0.0. POSIX Capabilities

A process has three sets of bitmaps called the inheritable(I), permitted(P), and effective(E) capabilities. Each capability is implemented as a bit in each of these bitmaps that is either set or unset.

When a process tries to do a privileged operation, the operating system will check the appropriate bit in the effective set of the process (instead of checking whether the effective uid of the process is 0 as is normally done).

For example, when a process tries to set the clock, the Linux kernel will check that the process has the CAP_SYS_TIME bit (which is currently bit 25) set in its effective set.

The permitted set of the process indicates the capabilities the process can use. The process can have capabilities set in the permitted set that are not in the effective set.

This indicates that the process has temporarily disabled this capability. A process is allowed to set a bit in its effective set only if it is available in the permitted set. The distinction between effective and permitted exists so that processes can "bracket" operations that need privilege.

The inheritable capabilities are the capabilities of the current process that should be inherited by a program executed by the current process. The permitted set of a process is masked against the inheritable set during exec(). Nothing special happens during fork() or clone(). Child processes and threads are given an exact copy of the capabilities of the parent process.

The implementation in Linux stopped at this point, whereas POSIX Capabilities[U5] requires the addition of capability sets to files too, to replace the SUID flag (at least for executables)

03.0.1. Capability Overview

The list of POSIX Capabilities used with Linux is long, and the 32 available bits are almost used up. While the detailed list of all capabilities can be found in /usr/include/linux/capability.h on most Linux systems, an overview of important capabilities is given here.

[0] CAP_CHOWN
change file ownership and group.
[5] CAP_KILL
send a signal to a process with a different real or effective user ID
[6] CAP_SETGID
permit setgid(2), setgroups(2), and forged gids on socket credentials passing
[7] CAP_SETUID
permit set*uid(2), and forged uids on socket credentials passing
[8] CAP_SETPCAP
transfer/remove any capability in permitted set to/from any pid
[9] CAP_LINUX_IMMUTABLE
allow modification of S_IMMUTABLE and S_APPEND file attributes
[11] CAP_NET_BROADCAST
permit broadcasting and listening to multicast
[12] CAP_NET_ADMIN
permit interface configuration, IP firewall, masquerading, accounting, socket debugging, routing tables, bind to any address, enter promiscuous mode, multicasting, ...
[13] CAP_NET_RAW
permit usage of RAW and PACKET sockets
[16] CAP_SYS_MODULE
insert and remove kernel modules
[18] CAP_SYS_CHROOT
permit chroot(2)
[19] CAP_SYS_PTRACE
permit ptrace() of any process
[21] CAP_SYS_ADMIN
this list would be too long, it basically allows to do everything else, not mentioned in another capability.
[22] CAP_SYS_BOOT
permit reboot(2)
[23] CAP_SYS_NICE
allow raising priority and setting priority on other processes, modify scheduling
[24] CAP_SYS_RESOURCE
override resource limits, quota, reserved space on fs, ...
[27] CAP_MKNOD
permit the privileged aspects of mknod(2)\ Also see Examples [E01],[E02], and [E03].

03.1. Resource Limits

Resources for each process can be limited by specifying a Resource Limit. Similar to the Linux Capabilities, there are two different limits, a Soft Limit and a Hard Limit.

The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from zero up to the hard limit, and (irreversibly) lower its hard limit. A privileged process may make arbitrary changes to either limit value, as long as the soft limit stays below the hard limit.

03.1.0. Limit-able Resource Overview

The list of all defined resource limits can be found in /usr/include/asm/resource.h on most Linux systems, an overview of relevant resource limits is given here.

[0] RLIMIT_CPU
CPU time in seconds. process is sent a SIGXCPU signal after reaching the soft limit, and SIGKILL on hard limit.
[4] RLIMIT_CORE
maximum size of core files generated
[5] RLIMIT_RSS
number of pages the process's resident set can consume (the number of virtual pages resident in RAM)
[6] RLIMIT_NPROC
The maximum number of processes that can be created for the real user ID of the calling process.
[7] RLIMIT_NOFILE
Specifies a value one greater than the maximum file descriptor number that can be opened by this process.
[8] RLIMIT_MEMLOCK
The maximum number of virtual memory pages that may be locked into RAM using mlock() and mlockall().
[9] RLIMIT_AS
The maximum number of virtual memory pages available to the process (address space limit).

Also see Examples [E11], and [E12].

03.2. File Attributes

Originally, this feature was only available with ext2, but now all major filesystems implement a basic set of File Attributes that permit certain properties to be changed. Here again is a short overview of the possible attributes, and what they mean.

s SECRM
When a file with this attribute set is deleted, its blocks are zeroed and written back to the disk.
u UNRM
When a file with this attribute set is deleted, its contents are saved.
c COMPR
files marked with this attribute are automatically compressed on write and uncompressed on read. (not implemented yet)
i IMMUTABLE
A file with this attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file.
a APPEND
files with this attribute set can only be opened in append mode for writing.
d NODUMP
if this flag is set, the file is not candidate for backup with the dump utility.
S SYNC
updates to the file contents are done synchronously.
A NOATIME
prevents updating the atime record on files when they are accessed or modified.
t NOTAIL
A file with the t attribute will not have a partial block fragment at the end of the file merged with other files.
D DIRSYNC
changes to a directory having this attribute set will be done synchronously.\ Also see Examples [E13] and [E14].

03.3. The chroot(1) Command

chroot allows you to run a command with a different directory acting as the root directory. This means that all filesystem lookups are done with '/' referring to the substitute root directory and not to the original one.

While the Linux chroot implementation isn't very secure, it increases the isolation of processes with regards to the filesystem, and, if used properly, can create a filesystem "jail" for a single process or a restricted user, daemon or service.

See Example [E15]

[Summary] [Go Back] [Next]