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.


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.


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.





The scope is very flexible. It has to be.

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



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

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.


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:

Data-Code separation has a number of requirements:

Other thoughts:


HardenedUbuntu (last edited 2008-08-06 16:23:52 by localhost)