Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
Hi,
On Wed, 27 Jul 2011, Kees Cook wrote:
> > 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.
It's not really relevant for hardening options except that if we want to
make dpkg-buildflags a mandatory interface to retrieve the complete
set of build flags, it's important that the interface it offers can be used
in all cases.
> > QUESTION: Is this ok to assume that all build flags can be "delimited"
> > by a space character?
>
> For the hardening flags, yes.
The question was more general because it's a generic interface for
dpkg-buildflags and it should handle any build flag that might
realistically be used.
> > 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?
> I see three remaining issues:
I think all those issues are to be sorted between you and me, and
do not need the involvment of the technical committee (but obviously
I always welcome review by anyone even of TC members :)).
> - 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.
All the code is in libdpkg-perl and we can decide to have a specific
function that retrieves only the hardening build flags instead of all the
build flags.
That said, why should hardening-includes last any longer if
dpkg-buildflags offers everything it does?
> - 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.
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?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: