Bug 985592 - libtool + %global _hardened_build 1 = no full hardening
Summary: libtool + %global _hardened_build 1 = no full hardening
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libtool
Version: 28
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 978949
Blocks: Fedora28BuildFlags 1409738 1548473
TreeView+ depends on / blocked
 
Reported: 2013-07-17 20:01 UTC by Miloslav Trmač
Modified: 2019-04-03 14:40 UTC (History)
14 users (show)

Fixed In Version: libtool-2.4.6-24.fc28
Doc Type: Enhancement
Doc Text:
Clone Of: 978949
: 1409738 (view as bug list)
Environment:
Last Closed: 2018-04-27 04:10:21 UTC
Type: Bug


Attachments (Terms of Use)

Description Miloslav Trmač 2013-07-17 20:01:16 UTC
+++ This bug was initially created as a clone of Bug #978949 +++

Description of problem:

  When a package with hardening-flags explicitly enabled in specs-file
  builds a lib using autotools and/or libtool, the result always shows
  "partial" RELRO, only.  This is perfectly the expected result of a
  build when hardening-flags are NOT explicitly enabled in spec-file.


Version-Release number of selected component (if applicable):

  redhat-rpm-config-9.1.0-28.fc17.noarch
  redhat-rpm-config-9.1.0-37.1.fc18.noarch
  redhat-rpm-config-9.1.0-45.fc19.noarch
  redhat-rpm-config-9.1.0-45.fc20.noarch


How reproducible:

  always, when a package with hardening-flags enabled builds a lib using
  autotools and/or libtool


Steps to Reproduce:

  1. rpmbuild a random package which ships lib(s) using libtool during
     %%build and explicitly enables hardening-flags

  2. extract the build binary-rpm and run `hardening-check --color --verbose $file`
     on the libs shipped by that pkg

  3. rebuild the same pkg and disable hardening in spec-file

  4. repeat 2. on the new build pkg and compare the results - no difference

  5. rebuild the previous pkg, re-enable hardening and insert this
     scriptlet immediatly after invoking %configure-macro into it's spec-file:
     
       test -f ./libtool && \
       sed -i \
	   -e 's! \\\\\\$compiler_flags ! \\\\\\$CFLAGS \\\\\\$LDFLAGS -Wl,--as-needed&!g' \
           libtool ;

  6. repeat 2. on the new build pkg and compare the results - full hardening


Actual results:

  with hardening disabled, hardening-check reports:
     ...
     Read-only relocations: yes
     Immediate binding: no, not found!

  with hardening enabled, hardening-check reports:
     ...
     Read-only relocations: yes
     Immediate binding: no, not found!

  It's actually the same, which is not expected to be.  The one having hardening enabled
  shows "partial" RELRO, too.


Expected results:

  with hardening enabled, hardening-check reports:
     ...
     Read-only relocations: yes
     Immediate binding: yes

  The way it should be.  Hardening is applied completely.


Additional info:

  At least gdm (libgdm*.so*) and abrtd (libabrt*.so*) are directly affected
  by this bug.

  The attached patch will fix this problem by doing all needed changes without
  doing anything in a hardening-enabled spec-file.  This patch will fix the
  "unused-direct-shlib-dependency"-issue encoutered with some pakages, too.

--- Additional comment from Panu Matilainen on 2013-06-27 07:45:13 EDT ---

Has libtool upstream contacted on this particular issue?

From http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00003.html:
> This change is not correct, however.
> Linker flags are supposed to be interpreted by `libtool', because it may
> have to adjust (both itself and them).  Having LDFLAGS directly in
> $archive_cmds is just wrong, as it bypasses this.

So the sed-hack does something against upstream intentions, and while it might "fix" the hardening case, who knows what it might break? Not to mention such hacks are fragile to version changes and all.

CC'ing ajax, whose work the hardening-stuff in redhat-rpm-config is.

--- Additional comment from Matthew Miller on 2013-07-03 14:28:48 EDT ---

Can we do a more tailored fix which addresses just the hardening flags and not all of $compiler_flags ?

--- Additional comment from Björn Esser on 2013-07-10 03:33:59 EDT ---

Refactored my patch.  Now it just injects the gcc-spec with hardening ldflags.

Comment 1 Miloslav Trmač 2013-07-17 20:02:31 UTC
This bug is filed as a result of FESCo ticket https://fedorahosted.org/fesco/ticket/1132 .  While FESCo has asked for a short-term workaround in redhat-rpm-config, we would prefer to have a real fix in libtool.

Comment 2 Pavel Raiskup 2013-08-02 08:38:23 UTC
(In reply to Miloslav Trmač from comment #1)
> This bug is filed as a result of FESCo ticket
> https://fedorahosted.org/fesco/ticket/1132 .  While FESCo has asked for a
> short-term workaround in redhat-rpm-config, we would prefer to have a real
> fix in libtool.

Thanks for reporting this.  This should be fixed somehow upstream.  For this
particular case, allowing of forwarding the --specs= parameter to gcc from
LDFLAGS is enough (but more general solution for other parameters would be
nice).

Note that there exist -XCClinker, -Xlinker, -Xcompiler flags, but these does
not solve packaging problem with "globally" set $LDFLAGS (consider situation
without libtool).

Fix in libtool is long-term solution for us, for more info, please look at
Bug #978949.  But lets track upstream problem here.

Comment 4 Pavel Raiskup 2015-09-18 12:18:04 UTC
Upstream commit:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=702a97fbb09bd7

Comment 5 Mike McCune 2016-03-28 23:21:47 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 7 Florian Weimer 2018-04-18 17:49:27 UTC
Please release this as an update to Fedora 28, too.  Thanks.

Comment 8 Florian Weimer 2018-04-18 19:15:59 UTC
*** Bug 1548751 has been marked as a duplicate of this bug. ***

Comment 9 Fedora Update System 2018-04-20 14:27:46 UTC
libtool-2.4.6-24.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c7c0a0abcc

Comment 11 Fedora Update System 2018-04-21 18:38:23 UTC
libtool-2.4.6-24.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c7c0a0abcc

Comment 12 Fedora Update System 2018-04-27 04:10:21 UTC
libtool-2.4.6-24.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.