Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   Bug#552688: (http://www.linux-archive.org/debian-dpkg/557621-bug-552688-a.html)

Raphael Hertzog 07-27-2011 03:13 PM

Bug#552688:
 
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)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110727151330.GB17480@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110727151330.GB17480@rivendell.home.ouaza.com

Kees Cook 07-28-2011 08:57 PM

Bug#552688:
 
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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110728205742.GX4946@outflux.net">http://lists.debian.org/20110728205742.GX4946@outflux.net

Raphael Hertzog 07-28-2011 10:29 PM

Bug#552688:
 
On Thu, 28 Jul 2011, Kees Cook wrote:
> > 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. :)

Well, it's low-maintenance mode I hope so I have no problem merging your
patches whenever needed.

> I'm totally fine with h-i going away. The "hardening-check" script will
> need somewhere to live, though.

lintian? devscripts? dpkg-dev? I'm not sure what the best place is. But I
would really like lintian to check if all binaries are built with hardening
flags. It should probably not report any problem as long as one of
the hardening feature has been found.

That way it's still possible to disable some of the hardening features
without generating a warning that you have to override.

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

DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie" dpkg-buildflags

So yes it requires precise knowledge of the flag in use. To make this
less obnoxious I can certainly include a copy of the default flags
in the new /usr/share/dpkg/buildflags.mk file and let maintainer
use the variables listed there instead of hardcoding the precise set of
flags.

(I just did that in my pu/build-flags test branch)

But this is all rather verbose, maybe it's best to keep some separate
logic to enable/disable hardening features. Other opinions are welcome.
Maybe with a DEB_BUILD_MAINT_OPTIONS variable.

DEB_BUILD_MAINT_OPTIONS="hardening=-relro,+pie"

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

Maybe something like this:
DEB_BUILD_MAINT_OPTIONS="hardening=+pie:default"
DEB_BUILD_MAINT_OPTIONS="hardening=+pie:always"

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110728222917.GG3050@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110728222917.GG3050@rivendell.home.ouaza.com

Kees Cook 07-28-2011 10:55 PM

Bug#552688:
 
On Fri, Jul 29, 2011 at 12:29:17AM +0200, Raphael Hertzog wrote:
> On Thu, 28 Jul 2011, Kees Cook wrote:
> > That seems fine to me as long as I'm in a position to still be able to fix
> > bugs in the logic. :)
>
> Well, it's low-maintenance mode I hope so I have no problem merging your
> patches whenever needed.

Cool. Normally it's just been little things -- tweaking features, updating
documentation, or changing arch exclusions.

> > I'm totally fine with h-i going away. The "hardening-check" script will
> > need somewhere to live, though.
>
> lintian? devscripts? dpkg-dev? I'm not sure what the best place is. But I
> would really like lintian to check if all binaries are built with hardening
> flags. It should probably not report any problem as long as one of
> the hardening feature has been found.
>
> That way it's still possible to disable some of the hardening features
> without generating a warning that you have to override.

Lintian was where I have been planning to put it, but it's non-trivial. It
is easy to detect certain hardening features (BINDNOW, RELRO), but
stack-protector and _FORTIFY_SOURCE are not possible to detect that they
are strictly _missing_. For example, if a program doesn't use any string
arrays on the stack, it will have no protected stacks. Same for the
protected libc functions with fortify.

> > 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.
>
> DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie" dpkg-buildflags
>
> So yes it requires precise knowledge of the flag in use. To make this
> less obnoxious I can certainly include a copy of the default flags
> in the new /usr/share/dpkg/buildflags.mk file and let maintainer
> use the variables listed there instead of hardcoding the precise set of
> flags.
>
> (I just did that in my pu/build-flags test branch)

Excellent, I think this is the right thing to do. The flags do slowly
change over time (e.g. adding "--param ssp-buffer-size=4" to stack
protector).

Oh, eek, pointing out that example reminds me about the "can be space
separated?" question ... "--param ssp-buffer-size=4" has a space in the
middle! It should be safe to change this to "--param=ssp-buffer-size=4".
Sorry about missing that.

I'm still not sure what to do about the -fPIC vs -fPIE conflict for
cmake builds, though. I guess the documentation should just specifically
mention it and show how to filter for those cases. And it's not like it's
anything except -fPIC, so I don't think we need a whole system to deal with
it.

> But this is all rather verbose, maybe it's best to keep some separate
> logic to enable/disable hardening features. Other opinions are welcome.
> Maybe with a DEB_BUILD_MAINT_OPTIONS variable.
>
> DEB_BUILD_MAINT_OPTIONS="hardening=-relro,+pie"

This would be excellent.

> > 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.
>
> Maybe something like this:
> DEB_BUILD_MAINT_OPTIONS="hardening=+pie:default"
> DEB_BUILD_MAINT_OPTIONS="hardening=+pie:always"

I think just "+pie" is sufficient, due to how you wrote the supported
tests.

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110728225553.GK4946@outflux.net">http://lists.debian.org/20110728225553.GK4946@outflux.net


All times are GMT. The time now is 12:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.