On 25.10.2009 19:55, Kees Cook wrote:
Hello,
I would like to propose enabling[1] the GCC hardening patches that Ubuntu
uses[2]. Ubuntu has used it successfully for 1.5 years now (3 releases),
and many of the issues have already been fixed in packages that needed
adjustment[3]. After all this time, use of the hardening-wrapper[4]
package is still very low, so I think the right thing to do is to just fix
this in the compiler and everyone wins. I'm not suggesting that there
won't be added work to fix problems, but I believe that for Debian the
benefits now out-weigh the risks.
I do not expect to reach consensus with all developers on this, so I'm
not sure who I need to convince to move it forward. (Perhaps just the
GCC maintainers?) Regardless, if you agree with this, please speak up.
I think it's very important that this change happens.
Introducing hardening defaults is a project decision, but as you may know I
don't support the current approach to enable these defaults.
My candid commentary and possible trolling...
Arguments for:
- users of Debian become safer (real[5] security vulnerabilities are
either non-issues or reduced to a DoS).
- security team has less work to do.
- software quality improves by finding subtle bugs (and not just
packaged software -- anything compiled with the Debian gcc).
Arguments against:
- makes the compiler's behavior different than stock compiler.
Rebuttal: honestly, I don't care -- it seems like such a
huge win for safety and is easy to debug. Debian
already carries plenty of patches anyway -- there
is no such thing as the "stock compiler".
Honestly I do care. While the security team may have less work, you dump work on
the Debian GCC maintainers with a patch which is unmaintained upstream, and
which requires the compiler to be built with --disable-werror. Getting the
testsuite fixed took more than twelve months, and the changes to cleanly build
without --disable-werror are missing. The GCC packages don't "already carry
plenty of patches" of this style; you'll only see patches needed for packaging
or backports from upstream. I don't plan to have an exception for this patch
set. Please get the testsuite fixes accepted upstream, plus patches to build
without --disable-werror.
- makes more work for dealing with warnings.
Rebuttal: those warnings are there for a reason -- they can
be real security issues, and should be fixed.
there are some functions in glibc which are questionably declared with the "warn
about unused result" attribute (fwrite*). This seems to force a programming
style which not everybody agrees with (having to check the return value after
each operation instead of checking errno later).
- makes running Debian slower.
Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE
is compile-time. Run-time checks, including those from
-fstack-protector are just not measurable. The burden of
evidence for anyone claiming this is on them. I'm not
suggesting we turn on PIE; that option can be a problem.
no, the burden would be on you. You did claim the same for PIE without checking
yourself :-/ Please don't just check ix86.
Inflammatory observation: Debian may be the single remaining major Linux
distribution that does not use the stack protector and _FORTIFY_SOURCE
when building its packages. I find this embarrassing. Check[6] for
yourself.
The majority of distributions does turn on these options during package build
time, which IMO is the right thing to do. Debian should do the same. There's now
Raphael's new framework in place which makes the injection of macros in
dpkg-buildpackage in the environment obsolete.
Matthias
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
