Inactive Projects

There are a number of desired Linux Kernel hardening projects that are inactive and do not have an owner. This page gives details on some of them. If you plan to contribute (or are already contributing) to one of these projects, please email the kernel-hardening mailing list at kernel-hardening@lists.openwall.com and mention what you're covering.

Process Improvements

Security Code Review Guidelines

This project is an effort to provide a reference that educates subsystem maintainers on what to look for when performing security reviews/audits. This would include various classes of common coding vulnerabilities and how to detect them, as well as other best practices, such as not leaving private keys laying around.

Patch Signing

This project would provide support to determine if patches have been modified or tampered since they were signed.

Verification of Critical Subsystems

This project would provide verification of critical subsystems such as:

• Networking
• Network file systems
• KVM
• Cryptographic library
• Kernel build infrastructure

This could include approaches such as manual audits, static analysis, fuzzing testing, etc.

Development

There are several kernel hardening features that have appeared in other hardened operating systems that would improve the security of Linux. Some have been controversial, so attempts have been made 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.

Symlink Protection

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:

• 1996 Aug, Zygo Blaxell http://marc.info/?l=bugtraq&m=87602167419830&w=2
• 1996 Oct, Andrew Tridgell http://lkml.indiana.edu/hypermail/linux/kernel/9610.2/0086.html
• 1997 Dec, Albert D Cahalan http://lkml.org/lkml/1997/12/16/4
• 2005 Feb, Lorenzo Hernández García-Hierro http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1896.html

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.
  • Applications that break because of the change are easy to spot and fix. Applications that are vulnerable to symlink ToCToU by not having the change aren't.
• 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.

proposed upstream patch

Hardlink Protection

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:

• 1997 Dec, Yuri Kuzmenko http://lkml.org/lkml/1997/12/29/20
• 2002 Apr, Chris Wright http://lkml.org/lkml/2002/4/13/99

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 are easy to spot and can be tested and fixed. Applications that are vulnerable to hardlink attacks by not having the change aren't.
  • atd could be easily "repaired" by including a real uid==0 check, like Linux 2.4.x-ow does for that reason, or it might have been fixed since then, or better yet OpenBSD-derived crond should be used instead, which includes at(1) support (and it never had the problem with hardlinks). The latter solution also gets rid of a SUID root program (at(1) is SGID to group crontab then) and of a root-privileged daemon (cron and atd are replaced with just one crond).
  • Courier was only broken by the original most restrictive -ow patch; it was "repaired" in newer -ow patch revisions by adding the "or is writable by the current user" check, which is also present in the proposed patches below (in other words, Courier won't break with these patches)
• 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.

proposed upstream patch

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 one application (e.g. firefox) was compromised, it would be possible for an attacker to attach to other running processes (e.g. gpg-agent) to extract additional credentials and continue to expand the scope of their attack.

This is not a theoretical problem. SSH session hijacking and even arbitrary code injection is fully possible if ptrace is allowed normally.

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).

This behavior is controlled via the /proc/sys/kernel/yama/ptrace_scope sysctl value. The default is "1" to block non-child ptrace. A value of "0" restores the prior more permissive behavior, which may be more appropriate for some development systems and servers with only admin accounts. Using "sudo" can also grant temporarily ptrace permissions via the CAP_SYS_PTRACE capability, though this method allows the ptrace of any process.

proposed upstream patch