[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switch on compiler hardening defaults



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


Reply to: