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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org