[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]


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

> 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?

Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Reply to: