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