[Pkg-samba-maint] (forw) Introducing security hardening features for Lenny

Wed Jan 30 06:47:27 UTC 2008

Any thoughts by other package maitnainers about this?

Jerry, Jelmer, if you're reading this, your advice may be interesting

----- Forwarded message from Moritz Muehlenhoff <jmm at debian.org> -----

Date: Tue, 29 Jan 2008 22:16:24 +0100
From: Moritz Muehlenhoff <jmm at debian.org>
To: debian-devel-announce at lists.debian.org
Subject: Introducing security hardening features for Lenny
X-Mailing-List: <debian-devel-announce at lists.debian.org> archive/latest/951
X-CRM114-Status: Good  ( pR: 37.5098 )

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Debian archive is the biggest of all distributions and although
there's security support for all security issues being found, there's
still room for improvement and a need for increased resilience against
flaws not yet discovered.

A group of people have been working on introducing advanced security
hardening features into our archive:
http://alioth.debian.org/projects/hardening/ 

We recommend to activate the following features in individual packages
for now and discuss how to enable them system-wide later. (Matthias
Klose proposed a mechanism in debian-devel, which could be used for
it: http://lists.debian.org/debian-devel/2007/12/msg00090.html).

Some maintainers have already pro-actively enabled these features,
e.g. in the sendmail and openssh packages, but we're heading for
full archive coverage now.

There are two general classes of enhancements we'd like to apply to
Debian:

1. Tool chain features preventing the exploitation of some
vulnerability classes

Stack protector
===============

For a general introduction please see Wikipedia:
http://en.wikipedia.org/wiki/Stack-smashing_protection

This is relatively straight-forward. While it only addresses classic
stack buffer overflows, we still have a lot of poorly-reviewed
special case legacy code in our archive, so this will still be useful
in practice.

It's included in stock GCC since 4.1 onwards, so people would only
need to add the compile flags to their packages.

If there are packages which don't work with stack protection, it
can be overridden with a compile flag. (We would need a lintian
test to catch these, so that maintainers rather fix bugs in their
packages than circumventing it with disabling SSP.)

To enable, make sure that "-fstack-protector" ends up in the compiler flags.

Fortify Source
==============

This feature adds validation for internal C functions such as strcpy
for buffer sizes known during compile time. While vulnerabilities in
the functions it protects have become uncommon in high-profile apps,
it will be useful for fringe packages we have in the archive.

This feature is present in glibc since version 2.5, and is enabled
through the use of "-D_FORTIFY_SOURCE=2" and "-O2" or higher.

Format warnings
===============

For a general introduction please see Wikipedia:
http://en.wikipedia.org/wiki/Format_string_attack

This feature adds a higher level of warning reporting for functions using
format strings.  To enable, add "-Wformat" and "-Wformat-security" flags,
and pay attention to compile-time warnings.

2. Tool chain features enhancing the effectiveness of Address Space
Layout Randomization, which raises the bar for successful exploitation
of vulnerabilities.

For a general introduction please see Wikipedia:
http://en.wikipedia.org/wiki/Address_space_layout_randomization

relro
=====

This feature marks certain sections of the executable memory space
read-only after the linker has finished its work.  It serves as a
measure against GOT overwrites, which can make exploits more difficult.

This is enabled via "-Wl,zrelro".

Position Independent Executables
================================

Currently, modern kernels randomize the location of mmap and stack
allocation, but the text segment (and subsequent brk memory) is always
in the same place.  In kernels that support text ASLR, programs compiled
for PIE will gain full position randomization.  This has some known
problems on our more exotic archs, specifically hppa and m68k. These
tool chains should be patched, so that enabling PIE is a NOP instead of
forcing every maintainer to jump through hoops.

The flag -fPIE is very similar to -fPIC, but it applies to objects linked to
form the final executable binary.  PIE is enabled by passing "-fPIE" to all
object builds, and passing "-pie" to the final link.

Experimental wrapper package
============================

An experimental wrapper has been written, which is available in unstable:
http://packages.qa.debian.org/h/hardening-wrapper.html
It contains basic usage information.

You can use it to test compilation w/o much overhead. Lucas Nussbaum made
a complete archive rebuild and about 700 packages failed to build, mostly
due to problems with PIE:
http://people.debian.org/~lucas/logs/2007/11/26.hardening/00lists/

Once you've verified that your package builds and runs correctly, you should
add the necessary compiler/linker flags to your package's build system.

Once a distribution-wide way to add these flags is defined, you can switch
your package to it.

Scope of this proposal
======================

The target for Lenny is to enable these features in all applications
with potential security impact, specifically:

- - Your application is written in C / C++
- - If your package was subject to a DSA in the recent years
- - If your package parses files from untrusted sources
- - If your package communicates over a network

For some known flaky packages bugs will be filed.

Please be proactive with this.

If you file a bugreport requesting hardening features, please use the
usertag "hardening" for the user debian-security at lists.debian.org. If
you have a question wrt to fixing your package to enable hardening
features, please ask in debian-devel at lists.debian.org and add
missing information to the Wiki page available at
http://wiki.debian.org/Hardening

We'll probably need lintian tests to catch packages not enabling these
features at a later point.

Documentation
=============

Initial documentation is available at http://wiki.debian.org/Hardening

Discussion surrounding these hardening features can be seen on the list:
http://lists.alioth.debian.org/mailman/listinfo/hardening-discuss
(Initial discussion was mostly done in non-archived mail communication,
though)

Please add what you miss (especially if you are a porter documenting
arch-specific failure).

On behalf of the debian-hardening project (Kees, Marcus, Russell, Steve, 
Tim and myself): Happy hacking.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHn5bDXm3vHE4uyloRAq9YAKDfq0SZT9dT2KJy+MeaZYvVlKL43wCg1hZ+
sNkQ2HNIP5zJTCg66MghnoQ=
=22po
-----END PGP SIGNATURE-----

-- 
To UNSUBSCRIBE, email to debian-devel-announce-REQUEST at lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org

 ** CRM114 Whitelisted by: WHITELIST **

----- End forwarded message -----

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20080130/07817ba2/attachment-0001.pgp 