On Mon, Jan 24, 2011 at 01:26:00PM -0800, Don Armstrong wrote:
> On Fri, 21 Jan 2011, Kees Cook wrote:
> > This is likely the core of the disagreement: how to apply the flags.
> > I have a strong opinion about this because my perspective is
> > security-oriented. I think all compiles should be hardened; default
> > to being secure, and whitelist that which needs things disabled.
> > Same policy applies to firewalls, etc. As before, I stand by my
> > original email that started this thread:
> > http://lists.debian.org/debian-gcc/2009/10/msg00186.html
>
> 1) Can a complete patch to enable hardening by default include
> specific documentation on how to disable it? [Can this "return to a
> default compiler" be made simpler than switching the three or four
> options currently used?]
Anything is possible, but nothing like this exists at the moment. While it
might be possible to invent some kind of --no-hardening option that would
disable the defaults, it would take a non-trivial amount of time to
implement, especially since the defaults must currently be implemented in 3
separate ways (spec updates, warning state defaults, and built-in defines).
If this fell to me, I would probably want to fold this into getting the
upstream configure option accepted, but that's still down on my priority
list.
There are effectively 4 sets of options in the compiler hardening patches:
-Wformat -Wformat-security
-D_FORTIFY_SOURCE=2
-fstack-protector --param ssp-buffer-size=4
-Wl,-z,relro
I should mention: PIE (-pie -fPIE) is _not_ included in the compiler
defaults patch. This is only done via the hardening-wrapper
package. Building PIE by default in the compiler is something I haven't
finished testing. (Also note that included with PIE is -Wl,-z,now since
it's not hugely useful as a defensive ELF feature without PIE. Though since
it seems that with the symbol hash table now, there isn't a penalty in
using it so maybe it should become a stand-alone default. Needs more
research...)
> 2) The current state of the patch doesn't properly document that the
> flag is on by default; if the patch is enabled, it should say so in
> the documentation, not referencing a version of Ubuntu.
Sure, this could easily be changed. It does say things are on by default,
but the "since when" language would need to be changed to reflect the
inclusion of Debian.
> 3) Who is willing to do a complete rebuild with the patch enabled and
> handle filing any bugs (with appropriate patches, ideally) that turn
> up? [On how many architectures?]
Is there infrastructure to do a full archive rebuild on all architectures?
I've always filed bugs (usually with patches) in Debian for any issues I've
noticed in Ubuntu from building with the hardening options enabled, so at
least i386, amd64, powerpc, sparc, and armel should be relatively free from
complications. I do not know what to expect from hppa and m68k, but at
least hardening-wrapper has build-time tests and logic to avoid broken
situations -- this logic may need to be moved into the gcc package if the
defaults are enabled there (since Ubuntu builds only a subset of the Debian
archs).
> 4) What solution would you enact if the CTTE were to have hardening be
> on by default for all Debian packages, but disabled by default for the
> compiler as shipped?
One of the options would be to use hardening-wrapper with a config file
on the buildds. The wrapper already reads /etc/hardening-wrapper.conf,
so that DEB_BUILD_HARDENING=1 can be set globally. If the wrapper were
part of build-essential or pre-installed in the buildd chroots and the
buildds had this turned on (probably with DEB_BUILD_HARDENING_PIE=0
for archs that had low general register counts like ia32), the entire
archive would be built with hardening without any changes to the compiler.
I suspect some people will utterly hate this idea, though, but it will
work. Though the global defaults can even be explicitly disabled in a
build (debian/rules exporting DEB_BUILD_HARDENING=0, or some subset,
for example) if there were packages with specific issues.
-Kees
--
Kees Cook @debian.org
Attachment:
signature.asc
Description: Digital signature