Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
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
Reply to: