[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:50120] Fw: Introducing security hardening features for Lenny
やまねです。FYI.
lenny ではデフォルトでのセキュリティ強化が図られるようです。
Begin forwarded message:
Date: Tue, 29 Jan 2008 22:16:24 +0100
From: Moritz Muehlenhoff <jmm@debian.org>
To: debian-devel-announce@lists.debian.org
Subject: Introducing security hardening features for Lenny
-----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@lists.debian.org. If
you have a question wrt to fixing your package to enable hardening
features, please ask in debian-devel@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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org