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 <hert...@debian.org> > To: 552...@bugs.debian.org > Cc: debian-d...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org