PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Hi, 2016-05-15 4:11 GMT+02:00 Dimitri John Ledkov : > On 14 May 2016 at 21:12, Niels Thykier wrote: >> Marco d'Itri: >>> On May 03, Josh Triplett wrote: >>> While this doesn't make PIC absolutely free, it does eliminate almost all of the cost, to the point that it no longer seems worthwhile to build without -fPIC. Apart from that, building *all* code with -fPIC (including both programs and libraries) helps with hardening. >>> I think that this is worth exploring. >>> Did you check what other (relevant) distributions are doing? >>> >> >> Fedora seems to be doing -fPIE by default for executables[1] - targeting >> Fedora 23. Known issues they ran into can be found at [2]. >> I also found the following PPA [3]. Cannot say if it is official or >> just a personal interest from the PPA owner. >> > > Ubuntu 16.04 LTS on s390x has -fPIE and bind now > > Ubuntu 16.10 on amd64, ppc64el, s390x has -fPIE and bind now I think making PIE and bindnow default in dpkg (at least for amd64) would be perfect release goals for Stretch. This would make Debian on par with Fedora and Ubuntu in that regard. We briefly discussed that with Guillem in a related bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42 I think the next step could be an archive rebuild with the changed defaults if we would like to pursue this: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F I planned starting a discussion on debian-devel about PIE + bindnow, too, after checking all the packages which contain statically compiled binaries because they may need patching to disable PIE flags based on Lunar's post: https://people.debian.org/~lunar/blog/posts/aslr_now/ Cheers, Balint > > In general features like these for Ubuntu are tracked by Security team at: > > https://wiki.ubuntu.com/Security/Features > > And bind-now needs fixing on that page. > > -- > Regards, > > Dimitri. >
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Bálint Réczey: > Hi, > > [...] > Hi, > I think making PIE and bindnow default in dpkg (at least for amd64) would be > perfect release goals for Stretch. > I support the end goal, but I suspect we should enable PIE by default via GCC-6's new configure switch[1]. Assuming it does what I hope, then it will work better than enabling PIE via dpkg-buildflags. * The major issue with PIE by default is that it is not compatible with -fPIC (and presumably also -static), which causes FTBFS or broken ELF binaries. * Assuming the GCC option does what I hope, then it would automatically disable PIE for irrelevant outputs. My assumption seems to be aligned with the approach taking by Ubuntu. > This would make Debian on par with Fedora and Ubuntu in that regard. > FTR, Fedora seems to have some special logic for adding PIE only to executables. > We briefly discussed that with Guillem in a related bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42 > > I think the next step could be an archive rebuild with the changed defaults > if we would like to pursue this: > https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F > > I planned starting a discussion on debian-devel about PIE + bindnow, > too, after checking > all the packages which contain statically compiled binaries because > they may need patching > to disable PIE flags based on Lunar's post: > https://people.debian.org/~lunar/blog/posts/aslr_now/ > > Cheers, > Balint > >>[...] In summary: * I would welcome bindnow by default via dpkg-buildflags. * I would also love to have PIE as default for Stretch although I fear dpkg-buildflags is the wrong approach for that particular flag. Thanks, ~Niels [1] https://gcc.gnu.org/gcc-6/changes.html """The --enable-default-pie configure option enables generation of PIE by default.""" signature.asc Description: OpenPGP digital signature
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Hi Niels, 2016-05-15 20:49 GMT+02:00 Niels Thykier : > Bálint Réczey: >> Hi, >> >> [...] >> > > Hi, > >> I think making PIE and bindnow default in dpkg (at least for amd64) would be >> perfect release goals for Stretch. >> > > I support the end goal, but I suspect we should enable PIE by default > via GCC-6's new configure switch[1]. Assuming it does what I hope, then > it will work better than enabling PIE via dpkg-buildflags. > > * The major issue with PIE by default is that it is not compatible >with -fPIC (and presumably also -static), which causes FTBFS or >broken ELF binaries. > > * Assuming the GCC option does what I hope, then it would automatically >disable PIE for irrelevant outputs. > > My assumption seems to be aligned with the approach taking by Ubuntu. I agree that it would be the easier way and I also tried building packages with patched GCC 5 setting PIE as default with success, but we have a CTTE decision which says that we should set hardening flags through dpkg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688 > >> This would make Debian on par with Fedora and Ubuntu in that regard. >> > > FTR, Fedora seems to have some special logic for adding PIE only to > executables. > >> We briefly discussed that with Guillem in a related bug report: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42 >> >> I think the next step could be an archive rebuild with the changed defaults >> if we would like to pursue this: >> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F >> >> I planned starting a discussion on debian-devel about PIE + bindnow, >> too, after checking >> all the packages which contain statically compiled binaries because >> they may need patching >> to disable PIE flags based on Lunar's post: >> https://people.debian.org/~lunar/blog/posts/aslr_now/ >> >> Cheers, >> Balint >> >>>[...] > > In summary: > > * I would welcome bindnow by default via dpkg-buildflags. > > * I would also love to have PIE as default for Stretch although I fear >dpkg-buildflags is the wrong approach for that particular flag. I would be happy with either of the approaches. Cheers, Balint > > Thanks, > ~Niels > > [1] https://gcc.gnu.org/gcc-6/changes.html > > """The --enable-default-pie configure option enables generation of PIE > by default."""
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
On 15 May 2016 at 19:49, Niels Thykier wrote: > Bálint Réczey: >> Hi, >> >> [...] >> > > Hi, > >> I think making PIE and bindnow default in dpkg (at least for amd64) would be >> perfect release goals for Stretch. >> > > I support the end goal, but I suspect we should enable PIE by default > via GCC-6's new configure switch[1]. Assuming it does what I hope, then > it will work better than enabling PIE via dpkg-buildflags. > The configure switch is available in the debian gcc-5 toolchain as a cherrypick, which is not used. In the ubuntu build of the toolchain that switch is passed on previously mentioned releases / architectures. FYI, that switch is not perfect and -no-pie has to be used in a few places still. > * The major issue with PIE by default is that it is not compatible >with -fPIC (and presumably also -static), which causes FTBFS or >broken ELF binaries. > > * Assuming the GCC option does what I hope, then it would automatically >disable PIE for irrelevant outputs. > > My assumption seems to be aligned with the approach taking by Ubuntu. > >> This would make Debian on par with Fedora and Ubuntu in that regard. >> > > FTR, Fedora seems to have some special logic for adding PIE only to > executables. > >> We briefly discussed that with Guillem in a related bug report: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42 >> >> I think the next step could be an archive rebuild with the changed defaults >> if we would like to pursue this: >> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F >> >> I planned starting a discussion on debian-devel about PIE + bindnow, >> too, after checking >> all the packages which contain statically compiled binaries because >> they may need patching >> to disable PIE flags based on Lunar's post: >> https://people.debian.org/~lunar/blog/posts/aslr_now/ >> >> Cheers, >> Balint >> >>>[...] > > In summary: > > * I would welcome bindnow by default via dpkg-buildflags. > > * I would also love to have PIE as default for Stretch although I fear >dpkg-buildflags is the wrong approach for that particular flag. > > Thanks, > ~Niels > > [1] https://gcc.gnu.org/gcc-6/changes.html > > """The --enable-default-pie configure option enables generation of PIE > by default.""" > > -- Regards, Dimitri.
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
On 2016-05-15 21:45:55, Bálint Réczey wrote: > Hi Niels, > > 2016-05-15 20:49 GMT+02:00 Niels Thykier : > > Bálint Réczey: > >> Hi, > >> > >> [...] > >> > > > > Hi, > > > >> I think making PIE and bindnow default in dpkg (at least for amd64) would > >> be > >> perfect release goals for Stretch. > >> > > > > I support the end goal, but I suspect we should enable PIE by default > > via GCC-6's new configure switch[1]. Assuming it does what I hope, then > > it will work better than enabling PIE via dpkg-buildflags. > > > > * The major issue with PIE by default is that it is not compatible > >with -fPIC (and presumably also -static), which causes FTBFS or > >broken ELF binaries. > > > > * Assuming the GCC option does what I hope, then it would automatically > >disable PIE for irrelevant outputs. > > > > My assumption seems to be aligned with the approach taking by Ubuntu. > > I agree that it would be the easier way and I also tried building packages > with > patched GCC 5 setting PIE as default with success, but we have a CTTE > decision which says that we should set hardening flags through dpkg: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688 I'm not familiar with the history of that bug (272 updates!), so excuse my question, but: - that bug seems to have been opened in the context of custom patches to GCC, back in 2009-2012 - the CTTE seems to have made an informal decision (see last update #272) on that topic Would it make sense to re-evaluate that decision in the context of 2016, i.e. (if I understand correctly) no patching of GCC 6 needed? Just a quick ask to the CTTE asking if the decision is still valid given today's situation. regards, iustin
Bug#824448: ITP: r-bioc-interactivedisplaybase -- base package for enabling powerful shiny web displays of Bioconductor objects
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-interactivedisplaybase Version : 1.10.2 Upstream Author : Shawn Balcome * URL : http://bioconductor.org/packages/release/bioc/html/interactiveDisplayBase.html * License : Artistic-2.0 Programming Lang: GNU R Description : base package for enabling powerful shiny web displays of Bioconductor objects The interactiveDisplayBase package contains the basic methods needed to generate interactive Shiny based display methods for Bioconductor objects.
