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

Re: state of security hardening build flag efforts

On Sun, Apr 01, 2012 at 05:24:00PM +0800, Paul Wise wrote:
> On Sun, Apr 1, 2012 at 3:49 PM, Kees Cook wrote:
> > I'm going to work on getting this graphed daily, like the debhelper
> > statistics[3].
> If you do, please add that to the statistics wiki page:
> http://wiki.debian.org/Statistics

Ah-ha, yes. I will do that. :)

> Under what circumstances do you think GCC upstream should be enabling
> these options by default (as several distributions other than Debian
> do)?

I haven't attempted to push these things to upstream yet, but I still
think it would be a great idea. Magnus Granberg from Gentoo maintains
a patch against gcc for Gentoo, and has made attempts to upstream it,
but I'm not sure where it stands:

> Do you have any stats about where packages had to avoid enabling these options?

I have tried to encourage Ubuntu developers to keep track of stuff that
couldn't be trivially fixed here:

For everything else, I've tried to get patches either to the upstream
directly, or to Debian. The vast majority of those have been taken. It
was, honestly, a pretty short list since Gentoo did a ton of this
upstreaming of fixes when they started their hardening initiative. (RedHat
did a lot of work on hardening fixes too, but didn't tend to be very
effective at getting them upstreamed.)

I'm not sure how up to date that list, is though. I strongly suspect there
are things missing from it. :) But it's really just a handful of more
difficult problems vs the tens of thousands of packages in the archive.

Frankly, probably the most disruptive change was -Werror=format-security,
which wasn't enabled in Ubuntu (since fighting all the errors at once
seemed extremely daunting). Instead, I turned it on in hardening-wrapper,
and then via dpkg-buildflags to slowly ease it into the archive.

> Do you feel the frequency of that is low enough to enable these
> options by default (in upstream or in distros)?

Take my opinion with a grain of salt, as even I recognize that I'm a bit
of an extremist about this, but yes, absolutely. I succeeded in making
this happen in Ubuntu, and while the path is very different in Debian,
for package builds it is effectively "by default" now too (assuming
the package's build system is modern and the flags are passed into the
build correctly). As for the upstream compiler, I recognize they have
more users than just distro builders, but it seems to me that it is
irresponsible to not enable these features by default in the compiler. :)

Note that the default flags in both Ubuntu and Debian lack PIE (where
as Gentoo's hardening patchset includes PIE by default). The Debian
hardening documentation has encouraged maintainers to enable PIE too
if they have a sensitive package (daemons, media processors, browsers,
interpreters, etc), so it's not totally absent.

I'd like to see the default on architectures with enough general registers
(e.g. amd64) include PIE. The other archs, like i386, suffer quite a bit
(15% performance hit) in some cases, so while I think it should still be
the default there, it's not a decision I'm likely to be able to convince
more performance-sensitive people about.

I'd like to push for it on amd64 once more packages are building with
the default flags. We'd need the entire base system converted, though, to
deal with some of the build ordering problems with switching to PIE. The
problem is with shipped .a files: those object files must all be built
with -fPIE for them to link into a -pie binary. (i.e. all static users
of the .a need to be rebuilt after the .a is built.) It's doable, it
just needs to be done careful attention given to dependency ordering. I
don't think a specific flag-day would be needed.

> If you think that enabling them by default in GCC upstream is doable,
> what kind of blockers and timeframe would we expect for that?

I think the blockers are mostly political. There are no serious technical
blockers that I see (e.g. it _is_ enabled in the Ubuntu compiler). Getting
it into a form that upstream gcc would be happy about is the trick. I have
no sense of timeframe; I've not worked with the gcc upstream before.

> I would personally like binaries not built by debian/rules but built
> on Debian systems to be hardened by default.

Yup. I couldn't agree more, but that decision isn't mine and has already
been made.


Kees Cook                                            @debian.org

Reply to: