Creating a jail isolates a program from the rest of the file system. The idea is to create a sandbox, so entities the program does not need to access under normal operation are made inaccessible. This makes it much harder to abuse any vulnerability that can otherwise lead to unconstrained system compromise and consequently functions as a defense-in-depth strategy. A jail may consist of world-viewable programs that require fewer resources to execute than those that exist on that system. Jails are useful only when there is no way to elevate privileges in the event of program failure.
Additionally, care must be taken to ensure that all the required resources (libraries, files, and so on) are replicated within the jail directory and that no reference is made to other parts of the file system from within this directory. It is also advisable to administer restrictive read/write permissions on the jail directories and resources on the basis of the program's privilege requirements. Although creating jails is an effective security measure when used correctly, it is not a surrogate for compliance with the other rules and recommendations in this standard.
Noncompliant Code Example
A security flaw exists in this noncompliant code example resulting from the absence of proper canonicalization measures on the file path. This allows an attacker to traverse the file system and possibly write to a file of the attacker's choice with the privileges of the vulnerable program. For example, it may be possible to overwrite the password file (such as the
/etc/passwd, common to many POSIX-based systems) or a device file, such as the mouse, which in turn can aid further exploitation or cause a denial of service to occur.
An attacker can control the value of
argv and consequently access any resource on the file system.
This noncompliant code example also violates FIO02-C. Canonicalize path names originating from tainted sources and FIO03-C. Do not make assumptions about fopen() and file creation.
Compliant Solution (UNIX)
Some UNIX-based systems (such as OpenBSD) can restrict file system access by creating a
chroot() jail. The
chroot() jail requires care to implement securely [Wheeler 2003]. It is achieved by passing a predefined directory name as an argument to
chroot(). The call to
chroot() requires superuser privileges. However, this call does not leave the process inside the jail directory as might be expected. A subsequent
chdir() is required to restrict access to the jail boundaries.
Another essential step is to drop superuser privileges permanently after these calls (see POS02-C. Follow the principle of least privilege). The
chroot() system call is not secure against the superuser changing the current root directory (if privileges are not dropped). Successful jail creation prevents unintentional file system access even if an attacker gives malicious input, such as through command-line arguments.
An alternative sequence is to first call
chdir("chroot/jail") and then call
chroot("."). However, calling
chroot("/some/path"), should be avoided because this sequence may be susceptible to a race condition: an attacker with sufficient privileges can arrange for
/some/path to refer to different directories in the two system calls. Consequently, the program will not have its current working directory set to the new root directory. Using either
chdir() guarantees that the current working directory will be the same directory as the new root.
Failing to follow this recommendation may lead to full-system compromise if a file system vulnerability is discovered and exploited.
|Use of |
|Polyspace Bug Finder|
|CERT C: Rec. POS05-C|
Checks for file manipulation after chroot() without chdir("/") (rec. fully covered)
Search for vulnerabilities resulting from the violation of this rule on the CERT website.