Doc
Launchpad entry: none yet
Created: 2006-08-02 by JohnMoser
Contributors: JohnMoser
Packages affected:
Summary
This spec defines a documentation aspect of the Ubuntu Hardened Team specified in HardenedUbuntu: The Ubuntu Hardened Documentation Team.
Rationale
Security is a function of the developers' and the end users' understanding of the system. If the developers do not make a secure system, the end user is exposed to risks he can't fix; and if the end user does not know how to use the system, he will open up unnecessary security holes with bad configuration. It is therefor security-critical that good documentation exist for both the developers and the end user specifically relating to security.
Use cases
There are several.
Developer:
A new Ubuntu Hardened Audit Team member reads the Ubuntu Hardened Developer's Guide and begins to use scanelf to locate and fix TEXTRELs and executable stacks.
A user interested in security reads the Ubuntu Hardened Developer's Guide and begins to toy with elfsh and flawfinder, and crawl bugtraq. He eventually earns a spot on the Ubuntu Hardened Source Code Auditing Team and also helps the Ubuntu Hardened Vulnerability Team quite frequently.
- An end user is using Ubuntu as his development platform. He reads the Ubuntu Hardened Developer's Guide and finds information on writing secure code, auditing his own code, preventing executable stacks, and avoiding or removing TEXTRELs.
End User:
- Alice wants to use the hardened Ubuntu kernel instead of the stock. She reads the Ubuntu User's Guide section on security and learns how to properly use the grsecurity learning mode to develop policy for her system.
Bob wants to install openssh-server. The description points him to a section in the Ubuntu User's Guide; he finds documentation about disabling remote root log-in.
Scope
The scope of the documentation includes the following:
- Developer documentation
- Preface
- Explanation Ubuntu security policies and responsible disclosure practices
- Explanation of several common security attacks and concerns
Detailed descriptions of each security feature including address space randomization, GccSsp, PositionIndependentExecutables, and mandatory access control systems
- Descriptions of what security concerns each security feature mitigates, including example exploits where possible
- Details of the mechanism employed to correct these concerns
- Explanation of the general impact this has on what programs can do, if any
- Ubuntu Hardened Audit Team documentation
- Regression test suites for each security feature and instructions on using them
- Guide for locating and removing executable stacks
- Guide for locating and removing ELF TEXTRELs
Guide for fixing code that refuses to compile PIC to create PositionIndependentExecutables
Guide for fixing programs that depend on bad MemoryProtections
- Ubuntu Hardened Configuration Team documentation
- Explain the basic configuration issues that may arise
- Default configurations supplying known user names and passwords
- Default configurations enabling features that aren't commonly used
Default configurations that are generally wrong (i.e. sharing all directories, allowing NULL encryption...)
- Explain the basic configuration issues that may arise
- Ubuntu Hardened Kernel Team documentation
- List different available security patches used in the Ubuntu Hardened Kernel
- Explain who created each security patch and how to get in touch with them
- Explain what each patch does and why it's used
- Describe the order in which patches get stacked, based on which are most likely to eventually make Ubuntu stock kernel inclusion
- Vulnerability patches first, these definitely have to go to the stock kernel ASAP and should probably never be solely in the Hardened kernel
- Non-invasive patches next, in order based on opinions the Kernel team has voiced about inclusion in the Ubuntu stock kernel
- Patches with no chance of inclusion in the Ubuntu stock kernel last
- List different available security patches used in the Ubuntu Hardened Kernel
- Ubuntu Hardened Source Code Auditing Team documentation
- Explanation of how the Source Code Auditing Team interacts with other teams
- Explanation of how the Source Code Auditing Team interacts with other distributions and upstream projects
- Descriptions of various security issues that can be found in code written in various programming languages
- Guides for using auditing tools to supplement manual auditing
Source code auditing tools such as rats and flawfinder
Binary debugging tools such as elfsh and gdb
- Ubuntu Hardened Toolchain Team documentation
Documentation for each of the security features of the current gcc toolchain
- Descriptions of what security concerns each security feature mitigates, including example exploits where possible
- Details of the mechanism employed to correct these concerns
- Explanation of the general impact this has on what programs can do, if any
- Switches required to turn it on and off
Guide to gcc specs file hacking
Examples to turn features like GccSsp and PositionIndependentExecutables on by default
- Ubuntu Hardened Vulnerability Team documentation
- Explanation of the common classes of security vulnerabilities
- List of various sources of new vulnerability information
- Policies and procedures for releasing USNs
- Methods for contacting other distributions and upstream
- Preface
- User documentation
- Applying patches
Using update-notifier
- Enabling automatic security updates
- Secure passwords
- General password guidelines
Enabling pam secure password features
- PGP encryption
- Functions of PGP encryption
- Digital signatures
- Encryption
- Uses for PGP encryption
Instant Messaging using gaim plug-ins (which are unfortunately out of date)
- Installing and configuring Seahorse
- Generating or importing a PGP key
Using your PGP key in various applications such as Evolution, Thunderbird, Nautilus, gaim
- Functions of PGP encryption
- Description of Ubuntu's crash reporter
- What data it collects
- How to enable automatic reporting
- Advantages to automatic crash reporting
- Explanation of sensitive data
- Which data is not automatically sent
- How to review and send this data after a crash
- Description of Ubuntu's crash reporter
- Ubuntu security features
- Address space ranodmization
glibc heap corruption and double-free() detection
- Hardened kernel
- Mandatory access control policies
- Applying patches
Note that the scope is easily flexible and must change based on current technology, software, and Ubuntu policy.
Design
The developer's documentation will contain information for Ubuntu Hardened developers for all teams.
The user's documentation will contain basic, need-to-know information as well as a description of all Ubuntu security features.
The user's documentation should come in two flavors, possibly in the same documentation set:
Basic. Basic, need-to-know information in very friendly language. This needs to get the user to the "if something breaks I can click this button to fix it" point. Major technical details not needed for risk analysis by Joe User on his personal non-business machine can be left out; and our run-through of basic security features can be very brief and lightweight.
Advanced. Technical run-down in moderate detail to describe the theory and functionality of each of our security measures. Includes enough information to perform a risk-analysis of using Ubuntu and of disabling or altering any security policies in it; but also includes all of the basic "this is how you turn these things on and off" information in an easy-to-find manner. Security engineers are still people, the job is easier when the manual pretends to be For Dummies(TM).
Implementation
A LOT of documentation needs to be written.
Code
Data preservation and migration
Unresolved issues
Doc team should probably have documentation too, for style and formatting.
BoF agenda and discussion
HardenedUbuntu/Doc (last edited 2008-08-06 16:38:19 by localhost)