• Launchpad entry: none yet

• Created: 2006-08-01 by JohnMoser

• Contributors: JohnMoser

• Packages affected:

Summary

This spec and its subspecs describe a strategy for "upgrading" Ubuntu's security team into a team similar to the one at Hardened Gentoo.

This spec is currently an RFC.

Rationale

We need more than a leading edge on the latest patches to keep our machines safe. Ubuntu should support a proactive approach to security, utilizing strategic techniques to expose more bugs, give amortized security gains, and give absolute security guarantees.

Background

There are numerous interconnected and isolated projects dedicated to security. In 1994 OpenBSD was founded when Theo de Raadt split off from NetBSD; in 1996 Crispin Cowan of Immunex developed StackGuard, later to become ProPolice in 1999 at the interest of Hiraoki Itoh and Kuinkaze Yoda of IBM's Tokyo Research Lab; in 2000 an anonymous developer created PaX to implement an NX bit on i386 Linux, and later added strong address space randomization; in 2001 Brad Spengler created grsecurity, a number of security enhancements and an access control system built around PaX. In 2003 OpenBSD and RedHat came out with their own NX bit emulation that simply split the address space an executable and non-executable area; SELinux was also integrated with mainline Linux and released with 2.6 in 2003.

All of these projects have produced powerful security tools that can protect everyone from governments to businesses to the end user when properly deployed. Unfortunately, these tools are quite useless unless those deploying them understand the proper security considerations that have to be made. It's not just the tool; it's the way the tool is used. Policy has to be made about how and when to deploy the tool; audits have to be made to see where the tool is deployed and what it is and isn't protecting; and regression tests have to be run to determine if the tool has at some point been rendered inoperable by poor code or improper packaging and configuration. If users can't find out when the tool is working and be sure that it's actually working when you say it is, then they can't adequately formulate their own risk analysis.

To this end several teams exist that put a passion and dedication into properly deploying tools such as ProPolice, grsecurity, and SELinux. Gentoo's Security Team is bolstered by Gentoo's Hardened Team, who work diligently to provide a special security-hardened kernel; integrate a security-hardened toolchain including stack smash protection and PIE by default; and maintain mandatory access control policies for SELinux and grsecurity. Adamantix is an entire distribution forked from Debian that follows the same purpose. Both teams communicate with PaX and grsecurity developers; the SELinux mailing list; and upstream developers to solve security issues.

This kind of team differs from a normal security team in that they do not concern themselves strictly with vulnerabilities and patches; nor do they simply use the tools at their disposal and sit back to see what happens. These teams take an active role in the security community, using their expertise to steer the development of security tools and policy in the direction they need to go. It is this and only this proactive approach to security that will provide the greatest defenses our systems and our data will ever know.

Use cases

There are several.

Home:

• Linux has achieved 86.3% of the desktop market. Incidentally, someone has designed, coded, and released a polymorphic modular worm capable of mutating itself across various platforms and operating systems and communicating over an unidentifiable and untraceable encrypted peer-to-peer network. Alice doesn't want a worm.

Business:

• NURV wants to install a new core database server and wants something that will hold up if their perimeter security fails; they chose Ubuntu Server and apply patch updates once per month except for "Super Critical" patches (i.e. known exploitable) which get applied immediately.
• Ellingson Mineral gives its employees company laptops. Eugene Belford, their security administrator, recommends sticking with an operating system that won't get eaten as soon as it comes within range of somebody's wireless.

Government:

• For obvious reasons, NSA does not comment on operational uses.
• Richard Gill of the CIA wants his new lap-top to be "hacker proof." Ubuntu is installed on it because even if you mess up a lot, it's still hard to break into.

• The Department of Defense wants its back-end systems to supply reasonable security guarantees. It chooses Ubuntu because strong security systems are available that limit damage and prevent attacks on best effort (ignored), probabilistic (risk calculated), and absolute (100% effective) merit, allowing the DoD to form a mathematical model predicting the likelihood that any attack will succeed given various known and unknown vulnerabilities.

Scope

The scope is very flexible. It has to be.

Sub-specs of this spec define actual teams and duties of the teams.

Design

• The Ubuntu Hardened Team will be created to blanket all security operations of Ubuntu Linux.
• The base of the Ubuntu Hardened Team will include from-the-top control; individual teams do not make policy, they discuss policy and the top-level Ubuntu Hardened lead team makes the final decisions.
• The existing Ubuntu Security Team becomes a sub-team of Ubuntu Hardened.
• Other teams are forked off, such as an Audit team (source code auditing, QA regarding security features, etc).

Implementation

This spec has several sub-specs describing its implementation. These are:

• HardenedUbuntu/Audit - Audit Ubuntu to assure security features are all working.

• HardenedUbuntu/Configuration - Audit default configurations in Main packages for bad settings, i.e. excess enabled features, default users and passwords.

• HardenedUbuntu/Doc - Write security documentation and guides for developers and end users.

• HardenedUbuntu/Kernel - Maintain a security-hardened kernel with features not deemed suitable for Ubuntu stock kernel.

• HardenedUbuntu/SourceAudit - Coordinate and perform source code audits of critical packages.

• HardenedUbuntu/Toolchain - Maintained hardening features of the Ubuntu toolchain.

• HardenedUbuntu/Vulnerability - Locate, patch, and report vulnerabilities in packaged applications.

There are various teams handling different tasks. It is perfectly acceptable for the same developer to be in multiple teams; in fact this is preferable because overall involvement and understanding of what is going on is valuable to any team member. For example, a member of the Vulnerability and Audit teams may see a crasher bug that is not yet considered a vulnerability, and study it deeply as part of the Auditing process; this may lead to determining that the crasher is a security hole.

The from-the-top control of the base Ubuntu Hardened team will be formed only of members from Ubuntu Hardened sub-teams, preferably lead members. This will ensure that those making the final policy decisions will have a basic understanding of the decision to be made, rather than a bolted-on view of how a compiler works or what kinds of things you can do with kernel patches.

Code

Data preservation and migration

Unresolved issues

BoF agenda and discussion

A good opening is to discuss a stack of protections that prevent remote exploits from code injection (shellcode) or out-of-order execution (return-to-libc). Such a stack is as follows:

• Address Space Randomization. Good, sturdy address space randomization comes from the kernel. This confounds attacks because they rely on knowing where injected shellcode lies, or where library functions and injected stack frames are. Failed attempts crash the process with SIGSEGV or SIGILL.

  • Stack. The stack may be used to house shellcode or injected stack frames. Attackers must know the addresses these things were injected at for an attack to succeed.

  • mmap() base. The mmap() call starts mapping at one address and works its way down (up on old kernels); this is where libraries are mapped. Attackers performing return-to-libc attacks will inject false stack frames into the stack or heap and then return to functions in libraries; finding the stack frame and the function to be called involves breaking two layers of entropy, multiplying the probabilities of failure together.

  • Heap. The brk() segment has to be randomized separate from mmap() or main executable. It can be used to store data.

  • Main executable. The main executable must be randomized separately; only PositionIndependentExecutables can be moved. Attackers can bounce off the main executable to perform full calls into library functions and evade mmap() randomization.

• Data-Code Separation. Strictly separate non-executable and executable data, forcing an attacker to use two separately randomized memory segments (stack/heap for data and mmap() for libraries to return into). Data that is executable is never writable; data that is non-executable will never become executable. Without enforcing such separation, any program can voluntarily confound the issue, i.e. by using mprotect() or mmap(); if a program needs this that is fine, but if it does not then it should not be allowed to do it.

• PositionIndependentExecutables. The main executable can be moved around using VMA and segment tricks; this is a pain, and can cause crashes. A better solution is to simply build executables PIC, as with libraries. glibc is an example of a PIE.

Data-Code separation has a number of requirements:

• On i386 we need to emulate an NX bit. We could port the emulation from a number of places.

  • PaX tracks the code segment limit and keeps any memory above the highest executable mapping (in effect, just the stack) non-executable, while using a supervisor-bit overloading technique to keep the non-executable pages below that limit from being executed.

  • ExecShield provides only code segment limit tracking, which only protects the stack, and not at all times; it will always report protection on all non-executable pages, even if not actually protected.

• The Data-Code Separation can be applied in one of two methods:

  • SELinux policy controls execstack, execheap, execmem, and execmod can be applied for all programs except those which do not function with them. Those not conforming require investigation; some are by design, others are easy to correct.

  • PaX mprotect() could be used. We would have to port the policy hook from Gentoo to disable it on problem binaries; but it does have some checks for TEXTRELs.

Other thoughts:

• We may want to enable FORTIFY_SOURCE at level 1 with gcc. This performs compile-time checks but does not modify the code to use run-time verification.

• It would also be good to continue DerootificationStatus as far as possible. Ubuntu has made excellent progress here.

• AutomatedProblemReports can be used as a security device when we've mastered aggregating reports and finding duplicates.

• Some other interesting policy gems could be generated and mimic a lot of OpenWall or grsecurity.

  • /tmp restrictions on symlinks/hardlinks

  • /proc restrictions

---

CategorySpec