...
Additionally, care must be taken to ensure that all the required resources (such as libraries, files and so on) are replicated within the jail directory and 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 based on the program's privilege requirements. Although, creating jails is an effective security measure when used correctly, it is not a surrogate for additional security best practices.
Non-Compliant Code Example
A security flaw exists in the code shown below 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 his 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.
...
This non-compliant code example also violates FIO02-A. Canonicalize path names originating from untrusted sources and FIO03-A. Do not make assumptions about fopen() and file creation.
Compliant Solution (*NIX)
| Wiki Markup |
|---|
Some UNIX based systems (such as OpenBSD) encourage restricting file system access by recommending the creation of a {{chroot()}} jail. The {{chroot}} jail requires care to implement securely \[[Wheeler 03|AA. C References#Wheeler 03]\]. This is achieved by passing a predefined directory name as an argument to {{chroot()}}. The call to {{chroot()}} requires superuser privileges and as a result the program should be set-uid root. However, this call does not _leave_ the process inside the jail directory as one would expect. The {{chdir()}} call that follows does just this and is indispensable when access is to be restricted to within the jail boundaries. |
...
The chdir() system call may be susceptible to a race condition if called before chroot(). This is because an attacker with sufficient privileges can delete the 'jail' directory so that the chdir() operation fails and then recreate it so that chroot() succeeds. Consequently, the program will not start in its sandboxed environment (~/chroot/jail) and will not have its current working directory set to ~/chroot/jail. One mitigation strategy is to incorporate error checking to detect if chdir() failed. A more fool proof method is to use chdir() after chroot() so that it guarantees that the current working directory will be set to the chroot'ed directory, that is the new root.
Risk Assessment
Failing to follow this recommendation, wherever possible, may lead to full-system compromise if a security vulnerability is uncovered in a program or daemon.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MSC16 FIO17-A | medium | probable | high | P4 | L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[Wheeler 03|AA. C References#Wheeler 03]\] [Section 7.4, "Minimize Privileges"|http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privileges.html] |
...
MSC15FIO16-A. Do not depend on undefined behaviorAvoid reopening a file stream 1309. Miscellaneous Input Output (MSCFIO)