KernelHardening

Differences between revisions 1 and 14 (spanning 13 versions)
Revision 1 as of 2010-04-29 22:22:59
Size: 4711
Editor: c-76-105-168-175
Comment: initial brain dump
Revision 14 as of 2010-04-30 02:00:21
Size: 7286
Editor: c-76-105-168-175
Comment: clarify sticky
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
There are several kernel hardening features that have appeared in other hardened operating systems that would improve the security of Ubuntu, and Linux in general. They have been controversial, so this page attempts to describe the features, track their controversy and discussion over the years so as much information is available to make an educated decision about potential implementations. There are several kernel hardening features that have appeared in other hardened operating systems that would improve the security of Ubuntu, and Linux in general. They have been controversial, so this page attempts to describe them, including their controversy and discussion over the years, so as much information is available to make an educated decision about potential implementations.
Line 5: Line 5:
== Symlink Protection == <<TableOfContents>>
Line 7: Line 7:
A long-standing class of security issues is the symlink-based [[http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use|ToCToU]] race, most commonly seen in world-writable directories like `/tmp/`. == Proposed for Ubuntu ==
Line 9: Line 9:
The common method of exploitation of [[http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tmp+symlink|this flaw]] is crossing privilege boundaries when following a given symlink (i.e. a `root` user follows a symlink belonging to another user).  The solution is to not permit symlinks to be followed when users do not match, but only in a world-writable directory (with an additional improvement that the directory owner's symlinks can always be followed). === Symlink Protection ===

A long-standing class of security issues is the symlink-based
[[http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use|ToCToU]] race, most commonly seen in world-writable directories like `/tmp/`. The common method of exploitation of [[http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tmp+symlink|this flaw]] is crossing privilege boundaries when following a given symlink (i.e. a `root` user follows a symlink belonging to another user).

The solution is to not permit symlinks to be followed when users do not match, but only in a world-writable sticky directory (with an additional improvement that the directory owner's symlinks can always be followed, regardless who is following them).
Line 20: Line 24:
  * POSIX didn't consider this situation, and it's not useful to follow a broken specification at the cost of security.
 * Might break some unkno
wn application that uses this feature.
  * These applications cannot be identified, and as such, are few fewer than the applications that are vulnerable to symlink ToCToU.
 * Applications should just use `mkstemp()` or O_CREATE|`O_EXCL`.
  * POSIX didn't consider this situation, and it's not useful to follow a broken specification at the cost of security.  Also, please reference where POSIX says this.
 * Might break unknown applications that use this feature.
  *
These applications cannot be identified, and as such, are far fewer than the applications that are vulnerable to symlink ToCToU.
 * Applications should just use `mkstemp()` or `O_CREATE|O_EXCL`.
Line 26: Line 30:
== Hardlink Protection == [[http://people.canonical.com/~kees/0001-symlink-protection-logic.patch|Example implementation]]
Line 28: Line 32:
Hardlinks can be abused in a [[http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=hardlink|similar fashion]], but they are not limited to world-writable directories. If `/etc/` and `/home/` are on the same partition, a regular user can create a hardlink to `/etc/shadow` in their home directory. While it retains the original owner and permissions, it is possible for privileged programs that are otherwise symlink-safe to mistakenly access the file through its hardlink. Additionally, a very minor untraceable quota-bypassing local denial of service is possible by an attacker exhausting disk space by filling a world-writable directory with hardlinks. === Hardlink Protection ===

Hardlinks can be abused in a [[http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=hardlink|similar fashion]] to symlinks above, but they are not limited to world-writable directories. If `/etc/` and `/home/` are on the same partition, a regular user can create a hardlink to `/etc/shadow` in their home directory. While it retains the original owner and permissions, it is possible for privileged programs that are otherwise symlink-safe to mistakenly access the file through its hardlink. Additionally, a very minor untraceable quota-bypassing local denial of service is possible by an attacker exhausting disk space by filling a world-writable directory with hardlinks.

The solution is to not allow the creation of hardlinks to files that a given user would be unable to write to originally.
Line 37: Line 45:
  * POSIX didn't consider this situation, and it's not useful to follow a broken specification at the cost of security.
 * Might break atd, courier, and other unknown application that uses this feature.
  * POSIX didn't consider this situation, and it's not useful to follow a broken specification at the cost of security.  Also, please reference where POSIX says this.
 * Might break atd, courier, and other unknown applications that use this feature.
Line 43: Line 51:
== PTRACE Protection == === PTRACE Protection ===
Line 45: Line 53:
As Linux grows in popularity, it will become a growing target for malware. One particularly troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if Firefox was compromised, it would be possible for an attacker to attach to other processes to extract additional credentials and continue to expand the scope of their attack. Some applications use `prctl()` to specifically disallow such PTRACE attachment (e.g. ssh-agent), but a better solution is to only allow PTRACE directly from a parent to child process (i.e. direct `gdb` and `strace` still work), or from the root user (i.e. `gdb BIN PID`, and `strace -p PID` still work as root). As Linux grows in popularity, it will become a growing target for malware. One particularly troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if Firefox was compromised, it would be possible for an attacker to attach to other processes to extract additional credentials and continue to expand the scope of their attack.

For a solution, some applications use `prctl()` to specifically disallow such `PTRACE` attachment (e.g. `ssh-agent`). A more general solution is to only allow `PTRACE` directly from a parent to a child process (i.e. direct `gdb` and `strace` still work), or as the root user (i.e. `gdb BIN PID`, and `strace -p PID` still work as root).

== Not Currently Proposed For Ubuntu ==

=== chroot Protection ===

Many administrators attempt to contain potentially exploitable services in chroots. Unfortunately, chroots are not designed to be a security protection (they are for development and debugging). It is possible to reasonably contain a non-privileged process in a chroot, but attempting to contain a root user is fraught with pitfalls. While it is certainly possible to patch the kernel to have a hardened `chroot()` (for example, grsecurity has a large set of protections that lock down chroots) so many behaviors are changed and come in conflict with the more common development configurations.

Solutions are varied. Among the methods of chroot escape is manipulating the current working directory to be outside the current chroot via a second `chroot()` call (others include using `/proc/*/cwd`, `fchdir()`, and `PTRACE`). This single flaw is trivial to fix, but does not block the other avenues, so the gain is very small when compared with the down-side of carrying a delta from the upstream kernel.

A better solution is to side-step the problem entirely. Since these security protections are being designed correctly with containers (see [[Manpage:clone|CLONE_NEW*]]), it would be better to use containers or MAC from the start when trying to isolate a service.

Some links to the history of its discussion:

 * 2007 Sep, David Newall http://lkml.indiana.edu/hypermail/linux/kernel/0709.3/0721.html

Past objections and rebuttals could be summarized as:
 * Violates POSIX.
  * POSIX didn't consider or really define this situation, and it's not useful to follow a broken specification at the cost of security.
 * Might break `debootstrap`, `debian-installer`, and anything else that expects to `chroot()` within a chroot.
  * True, but maybe disallowing double-chroot is okay.
 * Can escape chroots in a large number of ways; containers are better.
  * Fix each flaw. Containers are not very easy to use yet.

[[http://people.canonical.com/~kees/0001-chroot-cwd-protection.patch|Example implementation of cwd fix]]

There are several kernel hardening features that have appeared in other hardened operating systems that would improve the security of Ubuntu, and Linux in general. They have been controversial, so this page attempts to describe them, including their controversy and discussion over the years, so as much information is available to make an educated decision about potential implementations.

Variations on these approaches have appeared in many projects, including OpenWall and grsecurity.

Proposed for Ubuntu

A long-standing class of security issues is the symlink-based ToCToU race, most commonly seen in world-writable directories like /tmp/. The common method of exploitation of this flaw is crossing privilege boundaries when following a given symlink (i.e. a root user follows a symlink belonging to another user).

The solution is to not permit symlinks to be followed when users do not match, but only in a world-writable sticky directory (with an additional improvement that the directory owner's symlinks can always be followed, regardless who is following them).

Some links to the history of its discussion:

Past objections and rebuttals could be summarized as:

  • Violates POSIX.
    • POSIX didn't consider this situation, and it's not useful to follow a broken specification at the cost of security. Also, please reference where POSIX says this.
  • Might break unknown applications that use this feature.
    • These applications cannot be identified, and as such, are far fewer than the applications that are vulnerable to symlink ToCToU.
  • Applications should just use mkstemp() or O_CREATE|O_EXCL.

    • True, but applications are not perfect, and new software is written all the time that makes these mistakes; blocking this flaw at the kernel is a single solution to the entire class of vulnerability.

Example implementation

Hardlinks can be abused in a similar fashion to symlinks above, but they are not limited to world-writable directories. If /etc/ and /home/ are on the same partition, a regular user can create a hardlink to /etc/shadow in their home directory. While it retains the original owner and permissions, it is possible for privileged programs that are otherwise symlink-safe to mistakenly access the file through its hardlink. Additionally, a very minor untraceable quota-bypassing local denial of service is possible by an attacker exhausting disk space by filling a world-writable directory with hardlinks.

The solution is to not allow the creation of hardlinks to files that a given user would be unable to write to originally.

Some links to the history of its discussion:

Past objections and rebuttals could be summarized as:

  • Violates POSIX.
    • POSIX didn't consider this situation, and it's not useful to follow a broken specification at the cost of security. Also, please reference where POSIX says this.
  • Might break atd, courier, and other unknown applications that use this feature.
    • These applications can be tested and fixed. The others, since they cannot be identified, are by definition fewer than the applications that are vulnerable to hardlink attacks.
  • Applications should correctly drop privileges before attempting to access user files.
    • True, but applications are not perfect, and new software is written all the time that makes these mistakes; blocking this flaw at the kernel is a single solution to the entire class of vulnerability.

PTRACE Protection

As Linux grows in popularity, it will become a growing target for malware. One particularly troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if Firefox was compromised, it would be possible for an attacker to attach to other processes to extract additional credentials and continue to expand the scope of their attack.

For a solution, some applications use prctl() to specifically disallow such PTRACE attachment (e.g. ssh-agent). A more general solution is to only allow PTRACE directly from a parent to a child process (i.e. direct gdb and strace still work), or as the root user (i.e. gdb BIN PID, and strace -p PID still work as root).

Not Currently Proposed For Ubuntu

chroot Protection

Many administrators attempt to contain potentially exploitable services in chroots. Unfortunately, chroots are not designed to be a security protection (they are for development and debugging). It is possible to reasonably contain a non-privileged process in a chroot, but attempting to contain a root user is fraught with pitfalls. While it is certainly possible to patch the kernel to have a hardened chroot() (for example, grsecurity has a large set of protections that lock down chroots) so many behaviors are changed and come in conflict with the more common development configurations.

Solutions are varied. Among the methods of chroot escape is manipulating the current working directory to be outside the current chroot via a second chroot() call (others include using /proc/*/cwd, fchdir(), and PTRACE). This single flaw is trivial to fix, but does not block the other avenues, so the gain is very small when compared with the down-side of carrying a delta from the upstream kernel.

A better solution is to side-step the problem entirely. Since these security protections are being designed correctly with containers (see CLONE_NEW*), it would be better to use containers or MAC from the start when trying to isolate a service.

Some links to the history of its discussion:

Past objections and rebuttals could be summarized as:

  • Violates POSIX.
    • POSIX didn't consider or really define this situation, and it's not useful to follow a broken specification at the cost of security.
  • Might break debootstrap, debian-installer, and anything else that expects to chroot() within a chroot.

    • True, but maybe disallowing double-chroot is okay.
  • Can escape chroots in a large number of ways; containers are better.
    • Fix each flaw. Containers are not very easy to use yet.

Example implementation of cwd fix

SecurityTeam/Roadmap/KernelHardening (last edited 2022-01-04 22:35:37 by rodrigo-zaiden)