Bug 1006299 - Missing RELRO hardening on loadable modules
Missing RELRO hardening on loadable modules
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jiri Denemark
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-10 08:07 EDT by Daniel Berrange
Modified: 2014-06-17 20:55 EDT (History)
6 users (show)

See Also:
Fixed In Version: libvirt-1.1.1-5.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 08:09:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
qemu.so's reloro log via readelf tool (489.00 KB, text/x-log)
2013-11-22 03:18 EST, Luwen Su
no flags Details

  None (edit)
Description Daniel Berrange 2013-09-10 08:07:04 EDT
Description of problem:
It is a goal for libvirt in RHEL-7 to have full RELRO hardening. Unfortunately we missed this for the loadable modules, per this upstream commit

commit f1f0e53b0814aab3c093f1219da95c0f836cdf4a
Author: Guido Günther <agx@sigxcpu.org>
Date:   Sun Sep 1 08:50:58 2013 +0200

    Pass AM_LDFLAGS to driver modules too
    
    This gives us a RO got, otherwise Debian's lintian complains:
    
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_vbox.so
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
    W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so
    W: libvirt-sanlock: hardening-no-relro usr/lib/libvirt/lock-driver/sanlock.so


Version-Release number of selected component (if applicable):
libvirt-1.1.1-4.el7

How reproducible:
Always

Steps to Reproduce:
1. Use 'eu-readelf -a' to look for the 'BIND_NOW' flag on every .so file in the libvirt RPMs
2.
3.

Actual results:
$ eu-readelf  -a /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so  | grep BIND_NOW


Expected results:
$ eu-readelf  -a /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so | grep BIND_NOW
  BIND_NOW          


Additional info:
Comment 4 Luwen Su 2013-11-22 03:18:21 EST
Created attachment 827614 [details]
qemu.so's reloro log via readelf tool
Comment 5 Luwen Su 2013-11-22 03:19:09 EST
Hi Jiri , 

I found both -4 version which don't have the patch and -12 version that don't have key word BIND_NOW but GNU_RELRO .

Is there a another way to prove that those file have full RELRO hardening ?
I upload the log of the command

#eu-readelf  -a /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so

with latest libvirt
Comment 6 Jiri Denemark 2013-12-02 07:59:37 EST
No idea. It was rpmdiff that complained about this and it stopped complaining once we added the patch :-)
Comment 7 Luwen Su 2013-12-31 02:12:01 EST
Jiri , could you provide a command line with rpmdiff to reproduce the hardening-no-relro warning on rhel ?

I try to used lintian  , but found there is no libvirt-1.1.1-4-bin any more on debians side , seems like they don't keep those old unstable package.

BTW , libvirt-1.2.0-bin passed without warning via lintian.
Comment 11 Ludek Smid 2014-06-13 08:09:30 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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