On Wed, Jul 27, 2011 at 05:13:30PM +0200, Raphael Hertzog wrote: > On Wed, 27 Jul 2011, Kees Cook wrote: > > > 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. > > How are they fixed? By adding DEB_BUILD_HARDENING_* := 0 in their > environment?
The Ubuntu gcc patch doesn't handle the DEB_BUILD_HARDENING_* flags, so the bulk of the fixes were for things that _FORTIFY_SOURCE and stack-protector caught, so the code itself was fixed either upstream or with a Debian-carried patch. Things that were built in Ubuntu with hardening-wrapper/includes were to explicitly gain PIE (since gcc already turned everything else on), so when they went weird they were fixed the same way (code fixes, upstream or Debian-carried patch). Most of the packages that had an Ubuntu delta of just h-w/i were taken by the Debian maintainers, so all of those packages should be sensible. > > - 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. > > It would not be reasonable for dpkg-dev to depend on hardening-includes so > my plan was basically to move this logic into dpkg-dev. But instead of > duplicating it we can find a way for hardening-includes to reuse the logic > that would be integrated in dpkg-dev. That seems fine to me as long as I'm in a position to still be able to fix bugs in the logic. :) > That said, why should hardening-includes last any longer if > dpkg-buildflags offers everything it does? I'm totally fine with h-i going away. The "hardening-check" script will need somewhere to live, though. And, as mentioned in the other thread, we need to figure out a sensible transition for the PIE bits, since it will likely start life in dpkg-buildflags globally disabled. > > - 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? > > If that's how current debian packages have been fixed, possibly yes at the > start but we would emit a warning explaining that package have to be > updated to use the new STRIP dpkg-buildflags operation. Maintainers transitioning from hardening-wrapper should just skip straight to STRIP since it's the same work moving from -wrapper to -includes. Maintainers transitioning from hardening-includes should be able to easily switch to STRIP, so I'm not sure it's worth supporting the h-i flags. Do you have an example of what the STRIP stuff would look like for a build? I don't want maintainers to have to know what all the individual flags are, especially since they might change, which is why I did what I did in h-i. > And at some point, the support for those env variables should be dropped. > > > - 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. > > Not sure I understand your problem. What's difficult in excluding > i386 from the set of architectures where PIE is used? Hopefully I explained this in the other thread. The situation is that everyone presently using h-w/i expects to build PIE, on architectures that _support_ it, including architectures that should not use it by _default_. So we need an easy way in a specific package to turn on PIE for architectures that support it, but for which we don't want it on by default. -Kees -- Kees Cook @debian.org -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
