Re: Switch on compiler hardening defaults
On Thu, 07 Jan 2010, Henrique de Moraes Holschuh wrote: > So, the question that needs an answer is: _why_ isn't it upstream yet? And that has been answered in another part of this thread. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, 05 Jan 2010, Michael Gilbert wrote: > On Wed, 6 Jan 2010 11:01:01 +0800 Paul Wise wrote: > > On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: > > > There is a maintained (by RedHat) patch for dealing with PIE. I already > > > > It is perfectly reasonable to reject patches until they are upstream. > > I personally will never add patches to Debian without either > > committing them upstream myself or some indication that they already > > have been or will be accepted upstream. IIRC the Debian kernel team > > has similar policies. Why hasn't RedHat upstreamed the patch? They are > > usually good about doing that. Perhaps you could push them to do so. > > While normally I would agree with your logic, when it comes to security > I think a more cautious logic must prevail. Remember that item 4 of It is exactly because of security that many of us frown *heavily* upon anything that is not submitted upstream. We _did_ learn our lesson from the OpenSSL problem. So, the question that needs an answer is: _why_ isn't it upstream yet? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Wed, 2010-01-06 at 21:46 +0100, Jan Kratochvil wrote: > All the GDB patches/data I have available are public. All the expressed > opinions are my personal ones unrelated to Red Hat or even the Archer > project. Thanks for the detailed and extensive information and your work on GDB. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Switch on compiler hardening defaults
On Wed, 06 Jan 2010 14:30:40 +0100, Marco d'Itri wrote: > On Jan 06, Julien Cristau wrote: > > > Remember that item 4 of the social contract states that: "Our > > > priorities are our users and free software." > > Every time you say that, god kills a kitten. Please, think of the > > kittens. > We need something like Godwin's law about it. Seems like you've detected Cristau's law :) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Bob Dylan and Tom Petty: Knockin' On Heaven's Door signature.asc Description: Digital signature
Re: Switch on compiler hardening defaults
On Wed, 06 Jan 2010 09:29:42 +0100, Paul Wise wrote: > > Hmm, OK. I'm quite surprised Fedora carries so many[1] patches to GDB, > > 1. http://cvs.fedoraproject.org/viewvc/rpms/gdb/devel/ Temporarily current "devel" is: http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/ (but you are right 99% of time it is normally /devel/) > > given their policy of staying close to upstreams[2]. > > > > Jan, as the maintainer of GDB in Fedora, can you comment on if/when > > Fedora's many many GDB patches GDB in recent years had no working upstream community. After I spent a lot of time preparing patches for upstream they usually got zero attention upstream. http://sourceware.org/ml/gdb-patches/2007-11/msg00438.html #0..6 Therefore I rather spent the time fixing problems of Red Hat customers. Situation changed in a last year+ primarily thanks to Tom Tromey working for Red Hat creating a new working upstream review & approving GDB community. It is still not perfect but it is far better than before. Still the Fedora patchset is large and it will take some time to merge it. I am going to give it some more time this year as the duties permit. Particularly thanks to the new PIE patch which finally made the Fedora patchset more coherent and with more stable results in my eyes. Generally downstream patches just make sense, such as: http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/gdb-bz533176-fortran-omp-step.patch?content-type=text%2Fplain&view=co The fix is fully working and it is a oneliner done in 5 minutes. But the right fix is to discuss a DWARF extension first at , implement the concluded DWARF extension producer in GCC and then implement the extension consumer in GDB. I would not manage to reach the current RHEL deadline such way. And why not to put the fully working fix also to Fedora when it has to be present in RHEL anyway. Particularly the Archer project was IMHO created for more flexible development model exchanging fast feature delivery for the cost of lower codebase cleanliness; similar to the Fedora downstream patchset goals. > > (particularly PIE support) will be merged upstream? The former Red Hat PIE support by Jeff Johnston of Red Hat worked when it was needed but it was not mergeable upstream as it was based on unfortunate principles (it was checking addresses at the time of initialized ld.so shared library list which is too late creating a chicken-and-egg problem). > > Has there been any attempt thus far at getting them merged? Therefore I rewrote it recently and posted the PIE patchset once: http://sourceware.org/ml/gdb-patches/2009-11/msg00167.html #0..15 But there were some updates since that time and I have not done a new merge and repost so far: http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/gdb-archer-pie-addons.patch?content-type=text%2Fplain&view=co http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/gdb-archer-pie-addons-keep-disabled.patch?content-type=text%2Fplain&view=co This should hopefully happen now during January. All the GDB patches/data I have available are public. All the expressed opinions are my personal ones unrelated to Red Hat or even the Archer project. Regards, Jan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Jan 06, Julien Cristau wrote: > > Remember that item 4 of the social contract states that: "Our > > priorities are our users and free software." > Every time you say that, god kills a kitten. Please, think of the > kittens. We need something like Godwin's law about it. -- ciao, Marco signature.asc Description: Digital signature
Re: Switch on compiler hardening defaults
On Wed, Jan 06, 2010 at 10:00:55AM +, Julien Cristau wrote: > On Tue, Jan 5, 2010 at 23:05:30 -0500, Michael Gilbert wrote: > > > Remember that item 4 of the social contract states that: "Our > > priorities are our users and free software." > > Every time you say that, god kills a kitten. Please, think of the > kittens. "Our priorities are our users and free software" "Our priorities are our users and free software" "Our priorities are our users and free software" ... "Our priorities are our users and free software" SCNR. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, Jan 5, 2010 at 23:05:30 -0500, Michael Gilbert wrote: > Remember that item 4 of the social contract states that: "Our > priorities are our users and free software." Every time you say that, god kills a kitten. Please, think of the kittens. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Wed, Jan 6, 2010 at 4:28 PM, Paul Wise wrote: > On Wed, Jan 6, 2010 at 12:37 PM, Kees Cook wrote: >> On Wed, Jan 06, 2010 at 11:01:01AM +0800, Paul Wise wrote: >>> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: >>> >>> > There is a maintained (by RedHat) patch for dealing with PIE. I already >>> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug, >>> > the gdb maintainer doesn't want it until it's in upstream. I, obviously, >>> > think that's ridiculous. PIE works and is useful. Blocking its rollout >>> > because gdb's support for it isn't upstream just furthers the catch-22. >>> >>> It is perfectly reasonable to reject patches until they are upstream. >>> I personally will never add patches to Debian without either >>> committing them upstream myself or some indication that they already >>> have been or will be accepted upstream. IIRC the Debian kernel team >>> has similar policies. Why hasn't RedHat upstreamed the patch? They are >>> usually good about doing that. Perhaps you could push them to do so. >> >> Normally, I'd totally agree. I do not know why RedHat has chosen to carry >> the PIE patches for 5 years[1], but they have. I[2] and others[3] >> have asked over the years, but no one with a deep enough understanding >> of the affected code has had the time to get it upstream. >> >> That said, the patches[4] in RedHat have a full test-suite associated with >> them. They're applied after their massive Archer patchset[5], so I had to >> fiddle pretty hard to get the PIE support working in the Debian package. >> >> As seen at the end of the Ubuntu gdb series file: >> >> # RH stack that seems to be needed for sane PIE handling >> gdb-6.3-test-pie-20050107.patch >> gdb-6.5-bz203661-emit-relocs.patch >> gdb-workaround-rh-stack-on.patch >> gdb-6.6-buildid-locate.patch >> gdb-6.3-pie-20050110.patch >> gdb-workaround-rh-stack-off.patch >> >> -Kees >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=130423 >> [2] http://sourceware.org/ml/gdb-patches/2008-05/msg00269.html >> [3] http://sourceware.org/ml/gdb/2006-08/msg00188.html >> [4] http://cvs.fedora.redhat.com/viewvc/devel/gdb/ >> [5] http://fedoraproject.org/wiki/Features/Archer > > Hmm, OK. I'm quite surprised Fedora carries so many[1] patches to GDB, > given their policy of staying close to upstreams[2]. > > Jan, as the maintainer of GDB in Fedora, can you comment on if/when > Fedora's many many GDB patches (particularly PIE support) will be > merged upstream? Has there been any attempt thus far at getting them > merged? It would also be nice if the patches had some metadata in > them, such as what is described in DEP-3. > > 1. http://cvs.fedoraproject.org/viewvc/rpms/gdb/devel/ > 2. http://fedoraproject.org/wiki/Staying_close_to_upstream_projects > 3. http://dep.debian.net/deps/dep3/ Bah, actually CCing this time. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Wed, Jan 6, 2010 at 12:37 PM, Kees Cook wrote: > On Wed, Jan 06, 2010 at 11:01:01AM +0800, Paul Wise wrote: >> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: >> >> > There is a maintained (by RedHat) patch for dealing with PIE. I already >> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug, >> > the gdb maintainer doesn't want it until it's in upstream. I, obviously, >> > think that's ridiculous. PIE works and is useful. Blocking its rollout >> > because gdb's support for it isn't upstream just furthers the catch-22. >> >> It is perfectly reasonable to reject patches until they are upstream. >> I personally will never add patches to Debian without either >> committing them upstream myself or some indication that they already >> have been or will be accepted upstream. IIRC the Debian kernel team >> has similar policies. Why hasn't RedHat upstreamed the patch? They are >> usually good about doing that. Perhaps you could push them to do so. > > Normally, I'd totally agree. I do not know why RedHat has chosen to carry > the PIE patches for 5 years[1], but they have. I[2] and others[3] > have asked over the years, but no one with a deep enough understanding > of the affected code has had the time to get it upstream. > > That said, the patches[4] in RedHat have a full test-suite associated with > them. They're applied after their massive Archer patchset[5], so I had to > fiddle pretty hard to get the PIE support working in the Debian package. > > As seen at the end of the Ubuntu gdb series file: > > # RH stack that seems to be needed for sane PIE handling > gdb-6.3-test-pie-20050107.patch > gdb-6.5-bz203661-emit-relocs.patch > gdb-workaround-rh-stack-on.patch > gdb-6.6-buildid-locate.patch > gdb-6.3-pie-20050110.patch > gdb-workaround-rh-stack-off.patch > > -Kees > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=130423 > [2] http://sourceware.org/ml/gdb-patches/2008-05/msg00269.html > [3] http://sourceware.org/ml/gdb/2006-08/msg00188.html > [4] http://cvs.fedora.redhat.com/viewvc/devel/gdb/ > [5] http://fedoraproject.org/wiki/Features/Archer Hmm, OK. I'm quite surprised Fedora carries so many[1] patches to GDB, given their policy of staying close to upstreams[2]. Jan, as the maintainer of GDB in Fedora, can you comment on if/when Fedora's many many GDB patches (particularly PIE support) will be merged upstream? Has there been any attempt thus far at getting them merged? It would also be nice if the patches had some metadata in them, such as what is described in DEP-3. 1. http://cvs.fedoraproject.org/viewvc/rpms/gdb/devel/ 2. http://fedoraproject.org/wiki/Staying_close_to_upstream_projects 3. http://dep.debian.net/deps/dep3/ -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Hi, On Wed, Jan 06, 2010 at 11:01:01AM +0800, Paul Wise wrote: > On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: > > > There is a maintained (by RedHat) patch for dealing with PIE. I already > > maintain a delta for this in Ubuntu, but as you can see in the gdb bug, > > the gdb maintainer doesn't want it until it's in upstream. I, obviously, > > think that's ridiculous. PIE works and is useful. Blocking its rollout > > because gdb's support for it isn't upstream just furthers the catch-22. > > It is perfectly reasonable to reject patches until they are upstream. > I personally will never add patches to Debian without either > committing them upstream myself or some indication that they already > have been or will be accepted upstream. IIRC the Debian kernel team > has similar policies. Why hasn't RedHat upstreamed the patch? They are > usually good about doing that. Perhaps you could push them to do so. Normally, I'd totally agree. I do not know why RedHat has chosen to carry the PIE patches for 5 years[1], but they have. I[2] and others[3] have asked over the years, but no one with a deep enough understanding of the affected code has had the time to get it upstream. That said, the patches[4] in RedHat have a full test-suite associated with them. They're applied after their massive Archer patchset[5], so I had to fiddle pretty hard to get the PIE support working in the Debian package. As seen at the end of the Ubuntu gdb series file: # RH stack that seems to be needed for sane PIE handling gdb-6.3-test-pie-20050107.patch gdb-6.5-bz203661-emit-relocs.patch gdb-workaround-rh-stack-on.patch gdb-6.6-buildid-locate.patch gdb-6.3-pie-20050110.patch gdb-workaround-rh-stack-off.patch -Kees [1] https://bugzilla.redhat.com/show_bug.cgi?id=130423 [2] http://sourceware.org/ml/gdb-patches/2008-05/msg00269.html [3] http://sourceware.org/ml/gdb/2006-08/msg00188.html [4] http://cvs.fedora.redhat.com/viewvc/devel/gdb/ [5] http://fedoraproject.org/wiki/Features/Archer -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Wed, 6 Jan 2010 11:01:01 +0800 Paul Wise wrote: > On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: > > > There is a maintained (by RedHat) patch for dealing with PIE. I already > > maintain a delta for this in Ubuntu, but as you can see in the gdb bug, > > the gdb maintainer doesn't want it until it's in upstream. I, obviously, > > think that's ridiculous. PIE works and is useful. Blocking its rollout > > because gdb's support for it isn't upstream just furthers the catch-22. > > It is perfectly reasonable to reject patches until they are upstream. > I personally will never add patches to Debian without either > committing them upstream myself or some indication that they already > have been or will be accepted upstream. IIRC the Debian kernel team > has similar policies. Why hasn't RedHat upstreamed the patch? They are > usually good about doing that. Perhaps you could push them to do so. While normally I would agree with your logic, when it comes to security I think a more cautious logic must prevail. Remember that item 4 of the social contract states that: "Our priorities are our users and free software." An aspect of that guidance is providing high quality security for those users. Hence, when a feature improves security (or provides additional harding) the convenience factor of not differing from upstream should be considered a lower priority than normal. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: > There is a maintained (by RedHat) patch for dealing with PIE. I already > maintain a delta for this in Ubuntu, but as you can see in the gdb bug, > the gdb maintainer doesn't want it until it's in upstream. I, obviously, > think that's ridiculous. PIE works and is useful. Blocking its rollout > because gdb's support for it isn't upstream just furthers the catch-22. It is perfectly reasonable to reject patches until they are upstream. I personally will never add patches to Debian without either committing them upstream myself or some indication that they already have been or will be accepted upstream. IIRC the Debian kernel team has similar policies. Why hasn't RedHat upstreamed the patch? They are usually good about doing that. Perhaps you could push them to do so. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Thu, Dec 24, 2009 at 12:23:01PM +0100, Stefan Fritsch wrote: > On Thu, 24 Dec 2009, Kees Cook wrote: > >>>With the new package, the arch-specific logic for hardening defaults > >>>is in one place, and a maintainer can selectively disable anything they > >>>don't want on by default. > >> > >>This might be a good compromise to get network services hardened > >>without changing the default build system. Is there a plan for which > > > >That's certainly a viable plan. This is kind of the approach we took in > >Ubuntu for the PIE feature. We also considered packages with a less than > >stellar security history. The list of packages built with PIE in Ubuntu > >is: (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BuiltPIE ) > > > >amavisd-new apache2 asterisk bind9 cups cyrus-sasl2 dhcp3 dovecot exim4 > >ipsec-tools mysql-dfsg-5.1 nagios3 nagios-plugins ntp openbsd-inetd > >openldap openssh postfix postgreqsl-8.3 samba sendmail squid wireshark > >xinetd > > The problem with PIE is that it is not supported by Debian's gdb > (#346409). That's why I disabled it again for apache2. There is a maintained (by RedHat) patch for dealing with PIE. I already maintain a delta for this in Ubuntu, but as you can see in the gdb bug, the gdb maintainer doesn't want it until it's in upstream. I, obviously, think that's ridiculous. PIE works and is useful. Blocking its rollout because gdb's support for it isn't upstream just furthers the catch-22. > IIRC, there were also some apps (python?) that have performance > problems with PIE. Therefore, PIE should not be switched on by > default yet. Yes, some programs show slow-down on i386 and other architectures with limited registers. Those packages are exceptions, and should just disable PIE in their build when they add hardening-includes: DEB_BUILD_HARDENING_PIE:=0 -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sat, Dec 26, 2009 at 01:29:48AM +0100, Kurt Roeckx wrote: > On Tue, Oct 27, 2009 at 11:51:35PM +0100, Bastian Blank wrote: > > What would be a step forward: > > - Make any code PIC, including binaries (PIE) and static libs. > static libs would need to be PIE, not PIC. The differences between PIC and PIE are small. For all relevant architectures the only difference is to enable the shared libs assumptions for fPIC. > This is something that's not properly supported on all our arches. > Some people will also say it's too big a performance impact. I would only change this setting on a per-arch basis. It needs an additional register, but on most arches that should make no visible difference. Bastian -- You're dead, Jim. -- McCoy, "Amok Time", stardate 3372.7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, Oct 27, 2009 at 11:51:35PM +0100, Bastian Blank wrote: > What would be a step forward: [...] > - Make any code PIC, including binaries (PIE) and static libs. static libs would need to be PIE, not PIC. This is something that's not properly supported on all our arches. Some people will also say it's too big a performance impact. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Thu, 24 Dec 2009, Kees Cook wrote: > > Anyway, I'd appreciate a bug report against amavisd-new with whatever > > information is pertinent about PIE, if you guys want us to add it to the > > package. > > I already opened it in August when I added the patch for it in Ubuntu. :) > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542722 Ah, thanks. I did a quick look for "PIE", but missed "hardening". Either I or Alexander will get to implementing it. > > > I couldn't agree more. See /usr/share/hardening-includes/hardening.make > > > for details, but a package trying to avoid the hardening flags could just > > > set DEB_BUILD_HARDENING=0 in debian/rules. > > > > Can we get a standard DEB_BUILD_OPTIONS while that is still possible? > > DEB_BUILD_OPTIONS are external to the build, so I'm a bit unclear on the > benefit. Usually it's just for doing specialize builds (like noopt, > nostrip) or tweaking build behavior (parallel=N). I'd be happy to > implement the logic anyway, since it might help with debugging specific > build issues. I actually did this (though there are no users of it) in > dpkg-buildpackage in Ubuntu: Methinks "harden" or "not-harden", overriding the default for the package *is* a specialized build :) > Additionally, when used with the hardening-wrapper package, > the values "hardening" and "nohardening" will be converted into > their respective DEB_BUILD_HARDENING values. The "hardening" > option can also include (optionally prefixed with "no") the > following sub-options: "stackprotector" "format" "fortify" "pie" > "relro" For example, DEB_BUILD_OPTIONS=hardening=nopie would cause > DEB_BUILD_HARDENING_PIE=0 to be set, or DEB_BUILD_OPTIONS=nohardening > would cause DEB_BUILD_HARDENING=0 to be set. > > I could easily move this logic into hardening.make too. Does that sound > good? I like it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Hi Henrique, On Thu, Dec 24, 2009 at 03:25:32PM -0200, Henrique de Moraes Holschuh wrote: > On Thu, 24 Dec 2009, Kees Cook wrote: > > That's certainly a viable plan. This is kind of the approach we took in > > Ubuntu for the PIE feature. We also considered packages with a less than > > stellar security history. The list of packages built with PIE in Ubuntu > > is: (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BuiltPIE ) > > > > amavisd-new apache2 asterisk bind9 cups cyrus-sasl2 dhcp3 dovecot exim4 > > amavisd-new is perl, does that need PIE? Or do you mean the C utilities > (which are not network services but on the other hand are not > performance-sensitive anyway so might as well enable it just in case)? Right, though there are two ELFs in amavisd-new-milter. PIE is not the only benefit, it's just the only non-default hardening feature in Ubuntu, so we had an explicit list of programs that we wanted to be more complete with. > Anyway, I'd appreciate a bug report against amavisd-new with whatever > information is pertinent about PIE, if you guys want us to add it to the > package. I already opened it in August when I added the patch for it in Ubuntu. :) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542722 > > I couldn't agree more. See /usr/share/hardening-includes/hardening.make > > for details, but a package trying to avoid the hardening flags could just > > set DEB_BUILD_HARDENING=0 in debian/rules. > > Can we get a standard DEB_BUILD_OPTIONS while that is still possible? DEB_BUILD_OPTIONS are external to the build, so I'm a bit unclear on the benefit. Usually it's just for doing specialize builds (like noopt, nostrip) or tweaking build behavior (parallel=N). I'd be happy to implement the logic anyway, since it might help with debugging specific build issues. I actually did this (though there are no users of it) in dpkg-buildpackage in Ubuntu: Additionally, when used with the hardening-wrapper package, the values "hardening" and "nohardening" will be converted into their respective DEB_BUILD_HARDENING values. The "hardening" option can also include (optionally prefixed with "no") the following sub-options: "stackprotector" "format" "fortify" "pie" "relro" For example, DEB_BUILD_OPTIONS=hardening=nopie would cause DEB_BUILD_HARDENING_PIE=0 to be set, or DEB_BUILD_OPTIONS=nohardening would cause DEB_BUILD_HARDENING=0 to be set. I could easily move this logic into hardening.make too. Does that sound good? -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Thu, 24 Dec 2009, Kees Cook wrote: > That's certainly a viable plan. This is kind of the approach we took in > Ubuntu for the PIE feature. We also considered packages with a less than > stellar security history. The list of packages built with PIE in Ubuntu > is: (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BuiltPIE ) > > amavisd-new apache2 asterisk bind9 cups cyrus-sasl2 dhcp3 dovecot exim4 amavisd-new is perl, does that need PIE? Or do you mean the C utilities (which are not network services but on the other hand are not performance-sensitive anyway so might as well enable it just in case)? Anyway, I'd appreciate a bug report against amavisd-new with whatever information is pertinent about PIE, if you guys want us to add it to the package. > I couldn't agree more. See /usr/share/hardening-includes/hardening.make > for details, but a package trying to avoid the hardening flags could just > set DEB_BUILD_HARDENING=0 in debian/rules. Can we get a standard DEB_BUILD_OPTIONS while that is still possible? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Kees Cook writes: > And built with hardening-includes: > openbsd-inetd tcpdump -- Romain Francoise http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Thu, 24 Dec 2009, Kees Cook wrote: With the new package, the arch-specific logic for hardening defaults is in one place, and a maintainer can selectively disable anything they don't want on by default. This might be a good compromise to get network services hardened without changing the default build system. Is there a plan for which That's certainly a viable plan. This is kind of the approach we took in Ubuntu for the PIE feature. We also considered packages with a less than stellar security history. The list of packages built with PIE in Ubuntu is: (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BuiltPIE ) amavisd-new apache2 asterisk bind9 cups cyrus-sasl2 dhcp3 dovecot exim4 ipsec-tools mysql-dfsg-5.1 nagios3 nagios-plugins ntp openbsd-inetd openldap openssh postfix postgreqsl-8.3 samba sendmail squid wireshark xinetd The problem with PIE is that it is not supported by Debian's gdb (#346409). That's why I disabled it again for apache2. IIRC, there were also some apps (python?) that have performance problems with PIE. Therefore, PIE should not be switched on by default yet. For the other options, I agree. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
[dropped debian-gcc from the CCs as this is probably rather off topic now] Hi Petter, On Mon, Dec 21, 2009 at 08:16:08AM +0100, Petter Reinholdtsen wrote: > [Kees Cook] > > As an example, I have a debdiff against openssh to use it: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561887 > > > > With the new package, the arch-specific logic for hardening defaults > > is in one place, and a maintainer can selectively disable anything they > > don't want on by default. > > This might be a good compromise to get network services hardened > without changing the default build system. Is there a plan for which That's certainly a viable plan. This is kind of the approach we took in Ubuntu for the PIE feature. We also considered packages with a less than stellar security history. The list of packages built with PIE in Ubuntu is: (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BuiltPIE ) amavisd-new apache2 asterisk bind9 cups cyrus-sasl2 dhcp3 dovecot exim4 ipsec-tools mysql-dfsg-5.1 nagios3 nagios-plugins ntp openbsd-inetd openldap openssh postfix postgreqsl-8.3 samba sendmail squid wireshark xinetd Many of these (and others) are already building in Debian with hardening-wrapper: aria2 bind9 bird confget cookietool cups dma donkey grap hexer hfsprogs isoquery jd jed kaptain libdebug limo mysql-dfsg-5.1 nast postfix postgresql-8.3 postgresql-8.4 prips quagga robodoc rtpproxy ser slrn squid strongswan switchsh tnftp wireshark worker xmahjongg zoem And built with hardening-includes: openbsd-inetd > packages to convert first? A patch for my netplan package would be > most welcome. :) I guess starting with the most popular ones is a good > idea, and realise netplan is not one of these. :) Well, every package is a little different in how CFLAGS and LDFLAGS get passed into the upstream build, so there isn't a strict recipe. Probably the most common would be to declare CFLAGS and LDFLAGS to the "configure" environment. For example in debian/rules: include /usr/share/hardening-includes/hardening.make CFLAGS += $(HARDENING_CFLAGS) LDFLAGS += $(HARDENING_LDFLAGS) ... binary-arch: ... ... CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" ./configure ... You can check the results of the build with "hardening-check" (in hardening-includes version 1.19). See its manpage for more details. > Personally I would prefer the build default to change instead, and a > mechanism to disable in per package for those that can't use the > hardening defaults, but realise it might be a risky path to take. I couldn't agree more. See /usr/share/hardening-includes/hardening.make for details, but a package trying to avoid the hardening flags could just set DEB_BUILD_HARDENING=0 in debian/rules. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
[Kees Cook] > As an example, I have a debdiff against openssh to use it: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561887 > > With the new package, the arch-specific logic for hardening defaults > is in one place, and a maintainer can selectively disable anything they > don't want on by default. This might be a good compromise to get network services hardened without changing the default build system. Is there a plan for which packages to convert first? A patch for my netplan package would be most welcome. :) I guess starting with the most popular ones is a good idea, and realise netplan is not one of these. :) Personally I would prefer the build default to change instead, and a mechanism to disable in per package for those that can't use the hardening defaults, but realise it might be a risky path to take. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Hi, On Tue, Nov 24, 2009 at 09:38:41PM +0100, Moritz Muehlenhoff wrote: > On 2009-11-05, Kees Cook wrote: > > This would certainly be better than nothing, and better than the > > hardening-wrapper package, but it would require that every package in > > Debian be modified to respect external environments. Also, I think > > having the compiler itself be hardened is the bigger win. > > If doko feels uncomfortable with appyling the patches, we should use > the dpkg-buildpackage way (which I'm technically fine with). It also > has the nice side effect that we get a central place where we can > opt out architecture which don't implement a specific hardening feature. > It also allows maintainers to specifically opt out in cases where they > feel the overhead to be inacceptably high. (e.g., a number-crunching > math application). Right. So, the main problem is that I haven't seen a way to interact between dpkg-buildpackage and the rules file itself for cases where a maintainer wants to specifically disable a portion of the hardening (like PIE) without potentially interfering with the package's upstream configured flags. Instead, I've now implemented[1] a new binary package "hardening-includes" which provides a Makefile include[2] that can be used to get the (potentially arch-specific) hardening flags. As an example, I have a debdiff against openssh to use it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561887 With the new package, the arch-specific logic for hardening defaults is in one place, and a maintainer can selectively disable anything they don't want on by default. > > Out of curiosity, where can I and others find the documentation for the > > dpkg-buildpackage environment framework? We should immediately add the > > hardening options to it now for the packages that it will work on. > > See dpkg-buildpackage(1) in the section "ENVIRONMENT VARIABLES" Yeah, maybe I'm dense, but I didn't see a good way to selectively disable portions of the flags. It seems like it's better suited to things like -O2, etc (which it's doing already). > What flags do you intend to enable? -Wformat, -Wformat-security, > -D_FORTIFY_SOURCE=2 and -fstack-protector ? Also -fPIE/-fPIE -pie, -Wl,-z,relro, -Wl,-z,now I've also started work on a very simple hardening characteristic checker[3] that just looks for everything and reports back. This can be used to validate a built binary, etc. > Could you file a bug against dpkg-dev? If this approach works, perhaps debhelper could do the include automatically in a full dh 7 style rules file? -Kees [1] http://packages.qa.debian.org/h/hardening-wrapper/news/20091220T121706Z.html [2] http://svn.debian.org/wsvn/hardening/hardening-wrapper/hardening.make [3] http://svn.debian.org/wsvn/hardening/hardening-wrapper/hardening-check -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
["Followup-To:" header set to gmane.linux.debian.devel.general.] On 2009-11-05, Kees Cook wrote: >> The majority of distributions does turn on these options during >> package build time, which IMO is the right thing to do. Debian >> should do the same. There's now Raphael's new framework in place >> which makes the injection of macros in dpkg-buildpackage in the >> environment obsolete. > > This would certainly be better than nothing, and better than the > hardening-wrapper package, but it would require that every package in > Debian be modified to respect external environments. Also, I think > having the compiler itself be hardened is the bigger win. If doko feels uncomfortable with appyling the patches, we should use the dpkg-buildpackage way (which I'm technically fine with). It also has the nice side effect that we get a central place where we can opt out architecture which don't implement a specific hardening feature. It also allows maintainers to specifically opt out in cases where they feel the overhead to be inacceptably high. (e.g., a number-crunching math application). > Out of curiosity, where can I and others find the documentation for the > dpkg-buildpackage environment framework? We should immediately add the > hardening options to it now for the packages that it will work on. See dpkg-buildpackage(1) in the section "ENVIRONMENT VARIABLES" What flags do you intend to enable? -Wformat, -Wformat-security, -D_FORTIFY_SOURCE=2 and -fstack-protector ? Could you file a bug against dpkg-dev? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sun, Nov 01, 2009 at 08:10:44PM +0100, Samuel Thibault wrote: > > In general you cannot rely on checking errno because it is not defined > > whether a successful operation clears it. > > But you can clear it by hand before calling them. That's only true in some special cases; for example, SuSv3 says you should manually clear errno before calling functions in and you should check errno to see if the function was successful. But otherwise, even a successful operation may have called other operations internally that have failed and thus have modified errno. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sun, Nov 01, 2009 at 08:10:44PM +0100, Samuel Thibault wrote: > Ben Hutchings, le Sun 01 Nov 2009 19:06:59 +, a écrit : > > On Sun, 2009-11-01 at 19:53 +0100, Matthias Klose wrote: > > > there are some functions in glibc which are questionably declared with > > > the "warn > > > about unused result" attribute (fwrite*). This seems to force a > > > programming > > > style which not everybody agrees with (having to check the return value > > > after > > > each operation instead of checking errno later). > > In general you cannot rely on checking errno because it is not defined > > whether a successful operation clears it. > But you can clear it by hand before calling them. No, you can't. The value of errno is only defined after a failed call. It is undefined after a sucessfull call. You can see it as a special return value. Bastian -- It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, "The Trouble with Tribbles", stardate 4525.6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Ben Hutchings, le Sun 01 Nov 2009 19:06:59 +, a écrit : > On Sun, 2009-11-01 at 19:53 +0100, Matthias Klose wrote: > > On 25.10.2009 19:55, Kees Cook wrote: > [...] > > > - makes more work for dealing with warnings. > > > Rebuttal: those warnings are there for a reason -- they can > > >be real security issues, and should be fixed. > > > > there are some functions in glibc which are questionably declared with the > > "warn > > about unused result" attribute (fwrite*). This seems to force a > > programming > > style which not everybody agrees with (having to check the return value > > after > > each operation instead of checking errno later). > [...] > > In general you cannot rely on checking errno because it is not defined > whether a successful operation clears it. But you can clear it by hand before calling them. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sun, 2009-11-01 at 19:53 +0100, Matthias Klose wrote: > On 25.10.2009 19:55, Kees Cook wrote: [...] > > - makes more work for dealing with warnings. > > Rebuttal: those warnings are there for a reason -- they can > >be real security issues, and should be fixed. > > there are some functions in glibc which are questionably declared with the > "warn > about unused result" attribute (fwrite*). This seems to force a programming > style which not everybody agrees with (having to check the return value after > each operation instead of checking errno later). [...] In general you cannot rely on checking errno because it is not defined whether a successful operation clears it. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Re: Switch on compiler hardening defaults
On 25.10.2009 19:55, Kees Cook wrote: Hello, I would like to propose enabling[1] the GCC hardening patches that Ubuntu uses[2]. Ubuntu has used it successfully for 1.5 years now (3 releases), and many of the issues have already been fixed in packages that needed adjustment[3]. After all this time, use of the hardening-wrapper[4] package is still very low, so I think the right thing to do is to just fix this in the compiler and everyone wins. I'm not suggesting that there won't be added work to fix problems, but I believe that for Debian the benefits now out-weigh the risks. I do not expect to reach consensus with all developers on this, so I'm not sure who I need to convince to move it forward. (Perhaps just the GCC maintainers?) Regardless, if you agree with this, please speak up. I think it's very important that this change happens. Introducing hardening defaults is a project decision, but as you may know I don't support the current approach to enable these defaults. My candid commentary and possible trolling... Arguments for: - users of Debian become safer (real[5] security vulnerabilities are either non-issues or reduced to a DoS). - security team has less work to do. - software quality improves by finding subtle bugs (and not just packaged software -- anything compiled with the Debian gcc). Arguments against: - makes the compiler's behavior different than stock compiler. Rebuttal: honestly, I don't care -- it seems like such a huge win for safety and is easy to debug. Debian already carries plenty of patches anyway -- there is no such thing as the "stock compiler". Honestly I do care. While the security team may have less work, you dump work on the Debian GCC maintainers with a patch which is unmaintained upstream, and which requires the compiler to be built with --disable-werror. Getting the testsuite fixed took more than twelve months, and the changes to cleanly build without --disable-werror are missing. The GCC packages don't "already carry plenty of patches" of this style; you'll only see patches needed for packaging or backports from upstream. I don't plan to have an exception for this patch set. Please get the testsuite fixes accepted upstream, plus patches to build without --disable-werror. - makes more work for dealing with warnings. Rebuttal: those warnings are there for a reason -- they can be real security issues, and should be fixed. there are some functions in glibc which are questionably declared with the "warn about unused result" attribute (fwrite*). This seems to force a programming style which not everybody agrees with (having to check the return value after each operation instead of checking errno later). - makes running Debian slower. Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE is compile-time. Run-time checks, including those from -fstack-protector are just not measurable. The burden of evidence for anyone claiming this is on them. I'm not suggesting we turn on PIE; that option can be a problem. no, the burden would be on you. You did claim the same for PIE without checking yourself :-/ Please don't just check ix86. Inflammatory observation: Debian may be the single remaining major Linux distribution that does not use the stack protector and _FORTIFY_SOURCE when building its packages. I find this embarrassing. Check[6] for yourself. The majority of distributions does turn on these options during package build time, which IMO is the right thing to do. Debian should do the same. There's now Raphael's new framework in place which makes the injection of macros in dpkg-buildpackage in the environment obsolete. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Thu, 29 Oct 2009, Kees Cook wrote: > On Thu, Oct 29, 2009 at 10:01:08PM -0200, Henrique de Moraes Holschuh wrote: > > On Tue, 27 Oct 2009, Kees Cook wrote: > > > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: > > > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > > > > I would like to propose enabling[1] the GCC hardening patches that > > > > > Ubuntu > > > > > uses[2]. > > > > > > > > How do they work? Do they also change the free-standing compiler or only > > > > the hosted one? There is a lot of software, which (I would say) missuse > > > > the hosted compiler to build non-userspace-code, including the Linux > > > > kernel. > > > > > > The stack protector is conditional on being linked with libc, so, if you > > > build with -nostdlib (as the kernel does), it is implicitly disabled. > > > > This doesn't make sense. The kernel can, and does use stack protector > > functionality for its built if you ask it to. Do you mean the defaults are > > changed only when -nostdlib is NOT given? > > Yes, I was a bit unclear, sorry. The -fstack-protector option is not > added to the option list when either -fno-stack-protector or -nostdlib > are already in the option list. The GCC spec[1] for this is: That, and the fact that -fstack-protector-all is NOT used, removes all objections I might have: it means the kernel build won't be affected, and it preserves the decisions made by the kernel upstream about which files should get -fstack-protector and which files shouldn't. Thanks! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Thu, Oct 29, 2009 at 10:01:08PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 27 Oct 2009, Kees Cook wrote:
> > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > > I would like to propose enabling[1] the GCC hardening patches that
> > > > Ubuntu
> > > > uses[2].
> > >
> > > How do they work? Do they also change the free-standing compiler or only
> > > the hosted one? There is a lot of software, which (I would say) missuse
> > > the hosted compiler to build non-userspace-code, including the Linux
> > > kernel.
> >
> > The stack protector is conditional on being linked with libc, so, if you
> > build with -nostdlib (as the kernel does), it is implicitly disabled.
>
> This doesn't make sense. The kernel can, and does use stack protector
> functionality for its built if you ask it to. Do you mean the defaults are
> changed only when -nostdlib is NOT given?
Yes, I was a bit unclear, sorry. The -fstack-protector option is not
added to the option list when either -fno-stack-protector or -nostdlib
are already in the option list. The GCC spec[1] for this is:
%{!fno-stack-protector:%{!nostdlib:-fstack-protector}}
If you add -fstack-protector to a build (regardless of -nostdlib), gcc
will attempt to use the stack protector. This is how the kernel builds
when the CC_STACKPROTECTOR option is enabled.
And I can prove this works. :) The Ubuntu kernel uses both the hardened
compiler and the CC_STACKPROTECTOR option, and you can see the results on
an Ubuntu system:
$ readelf -s /lib/modules/$(uname -r)/kernel/fs/nfs/nfs.ko | grep stack_chk
1114: 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_fail
-Kees
[1]
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-ssp.diff
--
Kees Cook@debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, 27 Oct 2009, Kees Cook wrote: > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > > uses[2]. > > > > How do they work? Do they also change the free-standing compiler or only > > the hosted one? There is a lot of software, which (I would say) missuse > > the hosted compiler to build non-userspace-code, including the Linux > > kernel. > > The stack protector is conditional on being linked with libc, so, if you > build with -nostdlib (as the kernel does), it is implicitly disabled. This doesn't make sense. The kernel can, and does use stack protector functionality for its built if you ask it to. Do you mean the defaults are changed only when -nostdlib is NOT given? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Thu, 29 Oct 2009, Christoph Anton Mitterer wrote: > On Tue, 2009-10-27 at 22:19 -0200, Henrique de Moraes Holschuh wrote: > > Well, the issue raised in LKML is that you absolutely should *not* enable > > -fstack-protector-all unless you _really_ know what you're doing, and most > > certainly not by default. It has nothing to do with -fstack-protector, just > > with -fstack-protector-all. But it does show that extra stack usage CAN > > have bad effects on performance in pathological cases (which -all seems > > to cause more readly :-p ). > Isn't this what they've done starting with the 2.6.31 debian packages? > CONFIG_CC_STACKPROTECTOR_ALL=y > CONFIG_CC_STACKPROTECTOR=y > > Should we bugreport this agains src:linux2.6 ? I think so. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, 2009-10-27 at 22:19 -0200, Henrique de Moraes Holschuh wrote: > Well, the issue raised in LKML is that you absolutely should *not* enable > -fstack-protector-all unless you _really_ know what you're doing, and most > certainly not by default. It has nothing to do with -fstack-protector, just > with -fstack-protector-all. But it does show that extra stack usage CAN > have bad effects on performance in pathological cases (which -all seems > to cause more readly :-p ). Isn't this what they've done starting with the 2.6.31 debian packages? CONFIG_CC_STACKPROTECTOR_ALL=y CONFIG_CC_STACKPROTECTOR=y Should we bugreport this agains src:linux2.6 ? Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Hi, On Tue, Oct 27, 2009 at 10:19:22PM -0200, Henrique de Moraes Holschuh wrote: > On Tue, 27 Oct 2009, Kees Cook wrote: > > > > It seems the kernel will not be happy if the stack protector is switched > > > > on unconditionally: > > > > > > > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html > > > > > > Indeed. The kernel build system needs to be able to command whether > > > stackprotect is enabled or not without surprises... > > ... > > > Right, -fno-stack-protector via CFLAGS will disable it (as will > > -nostdlib). The work-arounds for the default are all documented both in the > > gcc manpage[1] (though this would need tweaking since it currently says > > "Ubuntu") and on the Ubuntu wiki page I mentioned earlier[2]. > > Well, the issue raised in LKML is that you absolutely should *not* enable > -fstack-protector-all unless you _really_ know what you're doing, and most > certainly not by default. It has nothing to do with -fstack-protector, just > with -fstack-protector-all. But it does show that extra stack usage CAN > have bad effects on performance in pathological cases (which -all seems > to cause more readly :-p ). > > http://osdir.com/ml/linux-kernel/2009-10/msg08763.html looks like an > horror tale (caused by -fstack-protector-all). Right, the kernel does its own thing, and isn't exactly related to this default. > Assuming you guys are _not_ enabling -fstack-protector-ALL by default, just > -fstack-protector, my only worry is this: Correct, -fstack-protector-all is not sane for the general case. Mildly related to this, I would note that while the upstream default for the compiler to decide between adding and not adding the prefix/suffix code to functions is when a function has an 8 byte stack or more. I noticed when examining SUSE builds that they seem to force this to 4 bytes (--param ssp-buffer-size=4). I do not have a strong opinion on this, and lacking further evidence, would stick to the 8 byte default. > What would happen if the kernel people start using -fstack-protector only on > _some_ files for very good reasons, and you end up with both the > -fno-stack-... and -fstack-... in a gcc invocation? AIUI, the kernel builds with -nostdlib, so gcc would not include -fstack-protector. Additionally, if -fno-stack-protector is seen on the invocation, no -fstack-protector is added. If, for some reason, something built with both -fno-stack-protector and -fstack-protector on the invocation, the latter setting wins. I don't think this will be problem. > Maybe this calls for a env. variable or special parameter (for CFLAGS) to > cause gcc stack-protector defaults not to be changed in that invocation (as > opposed to the direct use of -f and -fno). We'd need to use that on kernel > builds as well as on any packages that DO know about -fstack-protector to > avoid headaches and surprises long-term, I think. I don't see any reason to do this -- Ubuntu has used the -fstack-protector default for 3 years now. This is a very well tested area. (I'm not saying it'll be perfect, but I think the issues are well understood by a lot of people, and solutions will be straight forward.) -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, 27 Oct 2009, Kees Cook wrote: > > > It seems the kernel will not be happy if the stack protector is switched > > > on unconditionally: > > > > > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html > > > > Indeed. The kernel build system needs to be able to command whether > > stackprotect is enabled or not without surprises... ... > Right, -fno-stack-protector via CFLAGS will disable it (as will > -nostdlib). The work-arounds for the default are all documented both in the > gcc manpage[1] (though this would need tweaking since it currently says > "Ubuntu") and on the Ubuntu wiki page I mentioned earlier[2]. Well, the issue raised in LKML is that you absolutely should *not* enable -fstack-protector-all unless you _really_ know what you're doing, and most certainly not by default. It has nothing to do with -fstack-protector, just with -fstack-protector-all. But it does show that extra stack usage CAN have bad effects on performance in pathological cases (which -all seems to cause more readly :-p ). http://osdir.com/ml/linux-kernel/2009-10/msg08763.html looks like an horror tale (caused by -fstack-protector-all). Assuming you guys are _not_ enabling -fstack-protector-ALL by default, just -fstack-protector, my only worry is this: What would happen if the kernel people start using -fstack-protector only on _some_ files for very good reasons, and you end up with both the -fno-stack-... and -fstack-... in a gcc invocation? Maybe this calls for a env. variable or special parameter (for CFLAGS) to cause gcc stack-protector defaults not to be changed in that invocation (as opposed to the direct use of -f and -fno). We'd need to use that on kernel builds as well as on any packages that DO know about -fstack-protector to avoid headaches and surprises long-term, I think. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Mon, Oct 26, 2009 at 09:41:59PM +0100, Christoph Anton Mitterer wrote: > Ever thought about integrating PaX [0] per default in Debian? What features does the grsecurity patch provide currently? I know that several of the mentioned PaX features are supported in vanilla kernel in the meantime: - Non-executable memory on x86-32 with PAE. - Randomized stack and heap bases. - /dev/mem is highly restricted now, /dev/kmem removed. What would be a step forward: - Move all newer x86 32bit machines to PAE to support non-executable pages. - Make any code PIC, including binaries (PIE) and static libs. > I'm however not sure how much this actually breaks ;) It takes to much compile time configuration, so don't even think about it. Bastian -- Phasers locked on target, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, 2009-10-27 at 15:48 +0800, Paul Wise wrote: > http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines > http://kernel-handbook.alioth.debian.org/ch-source.html#s-acceptance The thing is,.. A patch like PaX would (IMHO) improve security a lot,... and it would be worth thinking for a distribution, whether to take this burden and to manually maintain it... Apart from that,.. if something like PaX is used in a mainline distro, it could get a development boost and perhaps be even included in the vanilla tree at some time. As PaX needs PIC as far as I remember, this decision would have to be made at a global level for the distribution anyway, as everything would have to be compiled with PIC. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, 2009-10-27 at 09:32 +0800, Paul Wise wrote: > Any idea if these patches will be merged upstream? It's probably quite unlikely,... although I never understood why,.. Even though it's available for some architectures,.. it would improve security at least on them. Cheers, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Hi,
On Tue, Oct 27, 2009 at 01:30:12PM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 26 Oct 2009, Gabor Gombas wrote:
> > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > > I would like to propose enabling[1] the GCC hardening patches that
> > > > Ubuntu
> > > > uses[2].
> > >
> > > How do they work? Do they also change the free-standing compiler or only
> > > the hosted one? There is a lot of software, which (I would say) missuse
> > > the hosted compiler to build non-userspace-code, including the Linux
> > > kernel.
> >
> > It seems the kernel will not be happy if the stack protector is switched
> > on unconditionally:
> >
> > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
>
> Indeed. The kernel build system needs to be able to command whether
> stackprotect is enabled or not without surprises...
>
> I assume very performance-critical applications will also need it disabled,
> if they have hot paths where dcache footprint matters. But I think we can
> safely assume these will be quite rare, so as long as one can disable the
> stackprotector easily enough through CFLAGS, we could just do it in a
> case-by-case basis on debian/rules.
Right, -fno-stack-protector via CFLAGS will disable it (as will
-nostdlib). The work-arounds for the default are all documented both in the
gcc manpage[1] (though this would need tweaking since it currently says
"Ubuntu") and on the Ubuntu wiki page I mentioned earlier[2].
The specific set of patch that would be enabled are:
-
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-format-security.diff
-
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-fortify-source.diff
-
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-relro.diff
-
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-ssp.diff
-
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/testsuite-hardening-format.diff
-
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/testsuite-hardening-fortify.diff
-
http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/testsuite-hardening-printf-types.diff
(I am trying[3], since they are general improvements, to get the latter
2 accepted by upstream gcc so our gcc package doesn't need to carry them.)
-Kees
[1] http://manpages.ubuntu.com/manpages/karmic/man1/gcc.1.html
...
NOTE: In Ubuntu 6.10 and later versions this option is enabled by default
for C, C++, ObjC, ObjC++, if neither @option{-fno-stack-protector}
nor @option{-nostdlib} are found.
...
[2] https://wiki.ubuntu.com/CompilerFlags
[3] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39536
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537
--
Kees Cook@debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Kees Cook, le Tue 27 Oct 2009 14:11:43 -0700, a écrit : > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > > uses[2]. > > > > How do they work? Do they also change the free-standing compiler or only > > the hosted one? There is a lot of software, which (I would say) missuse > > the hosted compiler to build non-userspace-code, including the Linux > > kernel. > > The stack protector is conditional on being linked with libc, so, if you > build with -nostdlib (as the kernel does), it is implicitly disabled. -nostdlib is a linker option, not a compiler option. The compiler would still emit references to __stack_chk_fail. What you probably mean is -ffreestanding, but it doesn't prevent references to __stack_chk_fail either, and it even produces TLS references, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838 Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > uses[2]. > > How do they work? Do they also change the free-standing compiler or only > the hosted one? There is a lot of software, which (I would say) missuse > the hosted compiler to build non-userspace-code, including the Linux > kernel. The stack protector is conditional on being linked with libc, so, if you build with -nostdlib (as the kernel does), it is implicitly disabled. -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Mon, 26 Oct 2009, Gabor Gombas wrote: > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > > uses[2]. > > > > How do they work? Do they also change the free-standing compiler or only > > the hosted one? There is a lot of software, which (I would say) missuse > > the hosted compiler to build non-userspace-code, including the Linux > > kernel. > > It seems the kernel will not be happy if the stack protector is switched > on unconditionally: > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html Indeed. The kernel build system needs to be able to command whether stackprotect is enabled or not without surprises... I assume very performance-critical applications will also need it disabled, if they have hot paths where dcache footprint matters. But I think we can safely assume these will be quite rare, so as long as one can disable the stackprotector easily enough through CFLAGS, we could just do it in a case-by-case basis on debian/rules. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, Oct 27, 2009 at 2:52 PM, Yves-Alexis Perez wrote: > On mar., 2009-10-27 at 09:32 +0800, Paul Wise wrote: >> On Tue, Oct 27, 2009 at 4:41 AM, Christoph Anton Mitterer >> wrote: >> >> > Ever thought about integrating PaX [0] per default in Debian? >> > I'm however not sure how much this actually breaks ;) >> >> Any idea if these patches will be merged upstream? > > I don't think so. I guess that answers the question of integrating PaX into Debian: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines http://kernel-handbook.alioth.debian.org/ch-source.html#s-acceptance -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On mar., 2009-10-27 at 09:32 +0800, Paul Wise wrote: > On Tue, Oct 27, 2009 at 4:41 AM, Christoph Anton Mitterer > wrote: > > > Ever thought about integrating PaX [0] per default in Debian? > > I'm however not sure how much this actually breaks ;) > > Any idea if these patches will be merged upstream? I don't think so. From the wikipedia page: As of mid 2004, PaX has not been submitted for the mainline kernel tree because The PaX Team does not think it yet appropriate; although PaX is fully functional on many CPU architectures, including the popular x86 architecture used by most, it still remains partially or fully unimplemented on some architectures. Those that PaX is effective on include IA-32(x86), AMD64, IA-64, Alpha, PA-RISC, and 32 and 64 bit MIPS, PowerPC, and SPARC architectures And I think there is periodically threads on LKML but can't find a relevant one quickly. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Switch on compiler hardening defaults
On Tue, Oct 27, 2009 at 4:41 AM, Christoph Anton Mitterer wrote: > Ever thought about integrating PaX [0] per default in Debian? > I'm however not sure how much this actually breaks ;) Any idea if these patches will be merged upstream? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Hi. Ever thought about integrating PaX [0] per default in Debian? I'm however not sure how much this actually breaks ;) Cheers, Chris. [0] http://pax.grsecurity.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Hi, On Mon, Oct 26, 2009 at 01:36:28PM +0100, Florian Weimer wrote: > * Kees Cook: > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > uses[2]. > > Seems a good idea to me. But I think we should defer the required > full archive rebuild until we've got the hardening patch for operator > new[] (which currently can return a heap block which is smaller than > requested). I've got a preliminary version, but it's got a hole when > operator new[] is invoked on a variable-length array. The easy fix > would probably to outlaw heap allocation of VLAs (it's one of those C > GCC extensions that leaked into C++, and it's arguably less needed for > C++). Right, I agree with this -- I figure this release can be seen as a transition release, where not everything is compiled that way. I don't want to introduce so much archive churn anyway. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
* Kees Cook: > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > uses[2]. Seems a good idea to me. But I think we should defer the required full archive rebuild until we've got the hardening patch for operator new[] (which currently can return a heap block which is smaller than requested). I've got a preliminary version, but it's got a hole when operator new[] is invoked on a variable-length array. The easy fix would probably to outlaw heap allocation of VLAs (it's one of those C GCC extensions that leaked into C++, and it's arguably less needed for C++). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > uses[2]. > > How do they work? Do they also change the free-standing compiler or only > the hosted one? There is a lot of software, which (I would say) missuse > the hosted compiler to build non-userspace-code, including the Linux > kernel. It seems the kernel will not be happy if the stack protector is switched on unconditionally: http://osdir.com/ml/linux-kernel/2009-10/msg07064.html Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > uses[2]. How do they work? Do they also change the free-standing compiler or only the hosted one? There is a lot of software, which (I would say) missuse the hosted compiler to build non-userspace-code, including the Linux kernel. Bastian -- History tends to exaggerate. -- Col. Green, "The Savage Curtain", stardate 5906.4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
> On Monday 26 October 2009 09:22:26 Marco d'Itri wrote: > > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > > uses[2]. > > > > Seconded. > > Thirded. > +1. Thanks for bringing this up, Michael pgpDxjsmOMyTR.pgp Description: PGP signature
Re: Switch on compiler hardening defaults
Kees Cook writes: > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > uses[2]. Ubuntu has used it successfully for 1.5 years now (3 releases), > and many of the issues have already been fixed in packages that needed > adjustment[3]. After all this time, use of the hardening-wrapper[4] > package is still very low, so I think the right thing to do is to just fix > this in the compiler and everyone wins. I'm not suggesting that there > won't be added work to fix problems, but I believe that for Debian the > benefits now out-weigh the risks. Agreed. The freeze is months away, there's plenty of time to deal with the potential fallout of enabling this, so let's just do it. -- Romain Francoise http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Monday 26 October 2009 09:22:26 Marco d'Itri wrote: > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > uses[2]. > > Seconded. Thirded. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Oct 25, Kees Cook wrote: > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > uses[2]. Seconded. hardening-wrapper does not looks like a solution to me since it execs perl for each call to gcc and ld when installed (even when inactive). And as you noticed, nobody uses it (starting with me). -- ciao, Marco signature.asc Description: Digital signature
Re: Switch on compiler hardening defaults
On Sun, Oct 25, 2009 at 03:21:01PM -0400, James Vega wrote: > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > Arguments against: > > - makes the compiler's behavior different than stock compiler. > > Rebuttal: honestly, I don't care -- it seems like such a > > huge win for safety and is easy to debug. Debian > > already carries plenty of patches anyway -- there > > is no such thing as the "stock compiler". > > - makes more work for dealing with warnings. > > Rebuttal: those warnings are there for a reason -- they can > > be real security issues, and should be fixed. > > - lacks documentation. > > Rebuttal: that may have been true a while ago, but I've worked > > hard to document the features and how to handle > > problems. See [2]. Even the gcc man pages are patched. > > - makes running Debian slower. > > Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE > > is compile-time. Run-time checks, including those from > > -fstack-protector are just not measurable. The burden of > > evidence for anyone claiming this is on them. I'm not > > suggesting we turn on PIE; that option can be a problem. > > - breaks debugging with gdb. See > <1256300822.13273.39.ca...@fsopti579.f-secure.com> on this list and #346409. > You provided a patch for #346409, but there appears to be issues with it as > noted in the bug log. > in the footnotes of Kees's email it said: (Note that the gcc hardening does NOT turn on PIE, which has measurable performance problems on some architectures.) so this isn't a problem. -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Re: Switch on compiler hardening defaults
On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > Arguments against: > - makes the compiler's behavior different than stock compiler. > Rebuttal: honestly, I don't care -- it seems like such a > huge win for safety and is easy to debug. Debian > already carries plenty of patches anyway -- there > is no such thing as the "stock compiler". > - makes more work for dealing with warnings. > Rebuttal: those warnings are there for a reason -- they can > be real security issues, and should be fixed. > - lacks documentation. > Rebuttal: that may have been true a while ago, but I've worked > hard to document the features and how to handle > problems. See [2]. Even the gcc man pages are patched. > - makes running Debian slower. > Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE > is compile-time. Run-time checks, including those from > -fstack-protector are just not measurable. The burden of > evidence for anyone claiming this is on them. I'm not > suggesting we turn on PIE; that option can be a problem. - breaks debugging with gdb. See <1256300822.13273.39.ca...@fsopti579.f-secure.com> on this list and #346409. You provided a patch for #346409, but there appears to be issues with it as noted in the bug log. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Switch on compiler hardening defaults
Hello, I would like to propose enabling[1] the GCC hardening patches that Ubuntu uses[2]. Ubuntu has used it successfully for 1.5 years now (3 releases), and many of the issues have already been fixed in packages that needed adjustment[3]. After all this time, use of the hardening-wrapper[4] package is still very low, so I think the right thing to do is to just fix this in the compiler and everyone wins. I'm not suggesting that there won't be added work to fix problems, but I believe that for Debian the benefits now out-weigh the risks. I do not expect to reach consensus with all developers on this, so I'm not sure who I need to convince to move it forward. (Perhaps just the GCC maintainers?) Regardless, if you agree with this, please speak up. I think it's very important that this change happens. My candid commentary and possible trolling... Arguments for: - users of Debian become safer (real[5] security vulnerabilities are either non-issues or reduced to a DoS). - security team has less work to do. - software quality improves by finding subtle bugs (and not just packaged software -- anything compiled with the Debian gcc). Arguments against: - makes the compiler's behavior different than stock compiler. Rebuttal: honestly, I don't care -- it seems like such a huge win for safety and is easy to debug. Debian already carries plenty of patches anyway -- there is no such thing as the "stock compiler". - makes more work for dealing with warnings. Rebuttal: those warnings are there for a reason -- they can be real security issues, and should be fixed. - lacks documentation. Rebuttal: that may have been true a while ago, but I've worked hard to document the features and how to handle problems. See [2]. Even the gcc man pages are patched. - makes running Debian slower. Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE is compile-time. Run-time checks, including those from -fstack-protector are just not measurable. The burden of evidence for anyone claiming this is on them. I'm not suggesting we turn on PIE; that option can be a problem. Inflammatory observation: Debian may be the single remaining major Linux distribution that does not use the stack protector and _FORTIFY_SOURCE when building its packages. I find this embarrassing. Check[6] for yourself. Thanks, -Kees [1] http://outflux.net/hardening-for-all.patch (Note that the gcc hardening does NOT turn on PIE, which has measurable performance problems on some architectures.) [2] https://wiki.ubuntu.com/CompilerFlags [3] Sampling of bugs I've personally filed: Closed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521108 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529074 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479398 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488456 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488457 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497833 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497865 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505734 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505233 Open http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523807 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488460 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488462 [4] http://wiki.debian.org/Hardening [5] Many vulnerabilities have been blocked in Ubuntu, but I will give one good example of a remote root vulnerability with functional exploits in the wild that was a non-issue on versions of Ubuntu with the hardened compiler defaults: http://www.debian.org/security/2009/dsa-1833 [6] Are there _chk functions in common binaries? $ objdump -R /bin/df | grep _chk 00612048 R_X86_64_JUMP_SLOT __fprintf_chk 00612068 R_X86_64_JUMP_SLOT __printf_chk 006120c0 R_X86_64_JUMP_SLOT __memcpy_chk 006121c0 R_X86_64_JUMP_SLOT __stack_chk_fail 00612220 R_X86_64_JUMP_SLOT __sprintf_chk 00612230 R_X86_64_JUMP_SLOT __snprintf_chk -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
