Bug 853199 - daemon programs should be compiled with PIE and full RELRO flags
Summary: daemon programs should be compiled with PIE and full RELRO flags
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On: 892837 958290
Blocks: 853068
TreeView+ depends on / blocked
Reported: 2012-08-30 17:19 UTC by Steve Grubb
Modified: 2013-05-24 20:16 UTC (History)
2 users (show)

Fixed In Version: NetworkManager-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-05-24 20:16:52 UTC
Type: Bug

Attachments (Terms of Use)
Patch that adds PIE and full RELRO (1.39 KB, patch)
2013-03-07 19:18 UTC, Steve Grubb
no flags Details | Diff
fix-gtk-doc-issue-with-hardened-build.patch (760 bytes, patch)
2013-04-30 20:29 UTC, Dan Williams
no flags Details | Diff

System ID Priority Status Summary Last Updated
GNOME Bugzilla 700093 None None None Never

Description Steve Grubb 2012-08-30 17:19:13 UTC
Description of problem:
Daemon programs should have full RELRO support enabled for extra protection. They should also have gcc's PIE flag enabled, too.

FILE                                                TYPE        RELRO    PIE 
/usr/bin/nm-online                                  daemon      partial  no  
/usr/sbin/NetworkManager                            daemon      partial  no  

You can use this program for testing:

Comment 1 Steve Grubb 2013-03-07 16:49:51 UTC
Checking to see if there is any progress on updating the compile flags. We'd like to close this bug if its already done. Thanks.

Comment 2 Dan Williams 2013-03-07 18:05:12 UTC
Does this mean we should be overriding the Fedora default compiler flags?  NM's specfile doesn't do anything special to whatever Fedora rpm macros set as the default.

Comment 3 Steve Grubb 2013-03-07 19:16:13 UTC
Yes it would be overriding Fedora's defaults. Daemons need more protection than a user program, especially if they run as root. The PIE flags will randomize the address space for the daemon every start so that certain classes of attacks are not possible. The relro flags make certain writable spots in memory read only. This also helps prevent attacks.

Comment 4 Steve Grubb 2013-03-07 19:18:16 UTC
Created attachment 706771 [details]
Patch that adds PIE and full RELRO

This patch solves the immediate problem. Perhaps a longer term solution is to detect support in configure and carry the flags to these two programs.

Comment 5 Dan Williams 2013-03-07 22:29:55 UTC
Is there a downside to making all the binaries PIE?

Comment 6 Steve Grubb 2013-03-08 00:06:45 UTC
The only downside is slower startup time. If its something used a lot in shell scripting, then it will be noticeable. That is why we are only asking for daemons - which are started on bootup and never again - to be PIE and full RELRO. The startup time difference is on the scale of milliseconds rather than whole seconds.

If you do something different than the patch above then please follow this note. Anything that has PIE flags set, should also be full RELRO, meaning its also passed the -Wl,-z,now linker flags. This is because when something is PIE, there is an extra segment added to the program that contains a lookup table for the functions. Full RELRO makes that readonly so that it cannot be attacked. Thanks.

Comment 7 Dan Williams 2013-03-08 15:32:50 UTC
Are the linker flags compatible with different linkers too, not just gcc's linker?  I know we've gotten patches from Debian people for 'gold' support.  I'm just trying to figure out whether we can just enable by default upstream or whether we need to some configure-time magic to detect what compiler you've got so we can enable the options by default.

Comment 8 Steve Grubb 2013-03-08 17:10:59 UTC
These flags are probably gcc specific. But I've seen other packages detect settings on the fly. For example, the suricata package does this:

        #forces all relocations to be resolved at run-time
        AC_MSG_CHECKING(for -z now)
        LDFLAGS="${LDFLAGS} -z now"

This can be extended for the PIE flags. RELRO and PIE have been around since RHEL5. So almost everyone should have it if they use gcc.

Comment 10 Dan Williams 2013-03-19 21:53:53 UTC
Was just reading the Fedora packaging guidelines, which say:


PIE adds security to executables by composing them entirely of position-independent code. Position-independent code (PIC) is machine instruction code that executes properly regardless of where in memory it resides. PIE allows Exec Shield to use address space layout randomization to prevent attackers from knowing where existing executable code is during a security attack using exploits that rely on knowing the offset of the executable code in the binary, such as return-to-libc attacks.

To use this in your spec, add:

%global _hardened_build 1

This adds -fPIC (if -fPIE is not already present) to the compiler flags, and adds -z now to the linker flags.

If your package meets any of the following criteria you MUST enable the PIE compiler flags:

    Your package is long running. This means it's likely to be started and keep running until the machine is rebooted, not start on demand and quit on idle. 

    Your package has suid binaries, or binaries with capabilities. 

    Your package runs as root. 

If your package meets the following criteria you should consider enabling the PIE compiler flags:

    Your package accepts/processes untrusted input. 

FESCo maintains a list of packages that MUST have PIE turned on. Other packages may enable the flags at the maintainer's discretion.

There are some notable disadvantages to enabling PIE that should be considered in making the decision:

    Some code does not compile with PIE (or does not function properly). 

    You can not use prelink on PIE enabled binaries, resulting in a slower startup time. 


So perhaps for now we can just add this to the NetworkManager specfile, build a new NM, verify that NM is built with the right flags, and then work on the upstream bits in parallel?

Comment 11 Dan Williams 2013-04-30 20:27:35 UTC
I just tried building NM with "%global _hardened_build 1" on F18 and got:

gcc: fatal error: /usr/lib/rpm/redhat/redhat-hardened-cc1: attempt to rename spec 'cc1_options' to already defined spec 'rh_cc1_options_old'
compilation terminated.
Compilation of scanner failed: 
make[3]: *** [scan-build.stamp] Error 1

gtk-doc's standard makefile that gets copied into the project makes the new hardened flags stuff angry, see:


I've filed bug 958290 for the gtk-doc fix.

Comment 12 Dan Williams 2013-04-30 20:29:06 UTC
Created attachment 741989 [details]

Comment 13 Dan Williams 2013-05-07 22:13:38 UTC
Patch fixes the issue locally, but apparently not on the buildsystem.  We really do want the redhat-rpm-config bug 892837 fixed.

Comment 14 Dan Williams 2013-05-09 21:02:29 UTC
Spent a bunch of time trying to get hardened_build to work and failed; we really do want the redhat-rpm-config bug fixed here.  Yes, we could theoretically work around it with a local patch to NM to stick pic/pie flags everywhere, but I'd rather get it fixed in redhat-rpm-config and use the standard Fedora construct.

Comment 15 Dan Williams 2013-05-10 16:01:21 UTC
Ok, got it working now I believe with some patches upstream to handle doc generation differently.  Are these results the ones we expect Steve?

FILE                                                     TYPE        RELRO    PIE 
/usr/bin/nm-online                                       daemon      full     yes 
/usr/bin/nm-tool                                         exec        full     yes 
/usr/bin/nmcli                                           exec        full     yes 
/usr/lib64/NetworkManager/libnm-settings-plugin-ifcfg-rh.so library     partial  DSO 
/usr/lib64/pppd/2.4.5/nm-pppd-plugin.so                  library     partial  DSO 
/usr/libexec/nm-avahi-autoipd.action                     exec        full     yes 
/usr/libexec/nm-dhcp-client.action                       exec        full     yes 
/usr/libexec/nm-dispatcher.action                        exec        full     yes 
/usr/sbin/NetworkManager                                 daemon      full     yes

Comment 16 Steve Grubb 2013-05-10 16:14:11 UTC
Thanks for the update. Yes, the two that needed to be PIE and Full RELRO are meeting the security requirements now. When you officially push it through the build system and schedule the updated package, feel free to close the bug. Thanks!

Comment 17 Dan Williams 2013-05-10 16:41:10 UTC
Will do; waiting for patch review upstream before I can build the snapshots for Fedora and RHEL.  https://bugzilla.gnome.org/show_bug.cgi?id=700093

Comment 18 Fedora Update System 2013-05-17 23:18:34 UTC
NetworkManager-,network-manager-applet- has been submitted as an update for Fedora 19.

Comment 19 Fedora Update System 2013-05-18 17:57:20 UTC
Package NetworkManager-, network-manager-applet-
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager- network-manager-applet-'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2013-05-24 20:16:52 UTC
NetworkManager-, network-manager-applet- has been pushed to the Fedora 19 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.