Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Hi,
Thanks for the forward! Comment below...
On Wed, Jul 27, 2011 at 12:03:24AM +0200, Raphael Hertzog wrote:
> Hi,
>
> see the attached mail I just sent to the tech-ctte bug about hardening
> build flags.
>
> Kees, it would be good to have your feedback.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Follow my Debian News ▶ http://RaphaelHertzog.com (English)
> ▶ http://RaphaelHertzog.fr (Français)
> Date: Tue, 26 Jul 2011 23:32:27 +0200
> From: Raphael Hertzog <hertzog@debian.org>
> To: 552688@bugs.debian.org
> Cc: debian-dpkg@lists.debian.org
> Subject: Bug#552688: Please decide how Debian should enable hardening build
> flags
>
> Hi,
>
> On Sat, 20 Nov 2010, Raphael Hertzog wrote:
> > I would really like Debian to build hardened binaries by default and it
> > would be great if the switch could happen early in the wheezy cycle. For
> > this I think we need to have a clear plan and I hope the technical
> > committee can bring some clarity here. Either by overruling the GCC
> > maintainer or by designing the missing pieces so that we can at least go
> > forward (I would implement what's needed in dpkg-dev if I knew what's
> > needed).
>
> So we just had some discussion with Steve Langasek, Ian Jackson, Bdale
> Garbee, me and Matthias Klose on this topic. I'll try to summarize the
> outcome here. It's probably a good idea to be familiar with the
> current dpkg-buildflags features before reading this mail, so check
> "man dpkg-buildflags" if needed.
>
> The consensus seems to be that we do not want to take the "gcc patch"
> approach and thus we're not going to overrule the maintainer. The bulk
> of the discussion then drifted on deciding how (hardening) build flags
> should be injected in the package build process.
For the record, I still think this is a mistake since then only built
packages are protected instead of everything the compiler builds. FWIW, I
intend to still use the gcc patch in Ubuntu.
> We evaluated how dpkg-buildflags can be used for this. For most
> autoconf/automake-based build systems there are 2 ways to inject flags:
> 1/ On the ./configure command line:
> ./configure --with-foo CFLAGS="..." LDFLAGS="..." ...
> 2/ In the environment
>
> The first form seem to be preferred but both approaches work and should be
> properly supported. However dpkg-buildflags does not easily support the
> former approach. This is something that should be fixed.
>
> TODO: implement "dpkg-buildflags --export=configure" that outputs
> “CFLAGS="…" LDFLAGS="…" ...” so that a maintainer can do
> ./configure --with-foo $(shell dpkg-buildflags --export=configure)
That seems like a good addition.
> Also up to now, dpkg-buildflags has only been designed to return the
> default build flags and it was my expectation that maintainers would
> tweak its output should this be necessary (either to add flags or to
> drop them, etc.).
>
> Unfortunately recent experience proved that dpkg-buildflags is likely to
> be called by various helpers and thus not in direct control of the
> maintainer via the rules files (unless all the helper provide their own
> way to do this but we really would like to avoid having severals ways
> to do the same thing). The current git version of dpkg already has support
> for debian/buildflags{,.<arch>} to allow maintainers to post-process
> the resulting buildflags but while this interface works for 95% of the
> easy cases, it can't cover them all because we have stuff like packages
> doing several builds of the same code with different build options (for
> example -Os for udebs) or adding flags depending on which compiler is
> actually in use. So the correct interface to feed post-processing
> instructions to dpkg-buildflags is environment variables (because this way
> we can call dpkg-builflags multiple times with different values to the
> environment variable as part of the debian/rules logic).
>
> TODO: revert debian/buildflags support, and implement
> support for the environment variable DEB_<flag>_MAINT_<operation> which
> work exactly like the corresponding DEB_<flag>_<operation> except it's
> meant to be used by the package maintainer within debian/rules.
I'm not sure how this will interact with hardening options, but okay.
> Another limitation of dpkg-buildflags thas has been brought up is that
> it only allows to append build flags and not to drop them. While it's
> often possible to disable some option by providing the opposite option
> later on the command line (e.g. "... --foo ... --no-foo"), it has been
> pointed out that the possibility to drop them is useful in particular when
> you would like to use another compiler that doesn't understand the
> option in question. Also it's cleaner as the resulting command line is
> shorter and more readable.
>
> TODO: add a "STRIP" operation to the set of operations supported by
> dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
> drop all occurrences of --foo and --bar in the returned build flags.
Right, this will be required for the PIE options (see the end of
/usr/share/hardening-includes/hardening.make for details).
> QUESTION: Is this ok to assume that all build flags can be "delimited"
> by a space character?
For the hardening flags, yes.
> Assuming that all those improvements are done, the consensus was that
> it's fine for dpkg-buildflags to start emitting the hardening build
> flags by default. According to Ubuntu's experience only a few dozen of
> packages are broken by the presence of these flags and those packages
> should just be updated to use the new STRIP operation to drop the
> problematic flags. This could be dealt as part of a wheezy release goal.
And a large portion of them are already fixed since Ubuntu reported the
bugs to Debian and most were fixed.
> Obviously those new flags will only be picked by packages already using
> dpkg-buildflags but that already includes packages using "dh" since it uses
> dpkg-buildflags to set the corresponding environment variable and
> also packages using CDBS (AFAIK). The other remaining packages would have
> to be updated by hand (and could also be part of a release goal).
>
> The discussion mainly covered automake/autoconf-based build systems and
> obviously there are some packages using alternate build systems where
> this out-of-the-box support by dh/CDBS will not be enough. In those cases,
> it's still up to the maintainer to adapt whatever is needed to feed
> the build flags in the appropriate way.
>
> Hopefully I have not forgotten anything important and I have correctly
> summarized the whole discussion (which was rather dense for a 1h
> discussion).
I see three remaining issues:
- by what mechanism will dpkg-buildflags use hardening-includes? It
wouldn't make sense to duplicate the existing arch-specific logic
that lives in hardening-includes.
- should the hardening flags presence still be controlled by the env
variables that are exposed as the existing interfaces defined by
hardening-wrapper/hardening-includes?
- there needs to be a way to identify those architectures that are
"register starved", since those should _not_ get the PIE flags by
default (e.g. i386 should not get PIE, but amd64 should get PIE by
default). Right now if one uses hardening-wrapper, it's expected
that everything that can be enabled is enabled, so you gain PIE
even on i386 at the moment.
-Kees
--
Kees Cook @debian.org
Reply to: