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.

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.

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.

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.

Is there a downside to making all the binaries PIE?

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.

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.

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)
        TMPLDFLAGS="${LDFLAGS}"
        LDFLAGS="${LDFLAGS} -z now"
        AC_TRY_LINK(,,SECLDFLAGS="${SECLDFLAGS} -z now"
        AC_MSG_RESULT(yes),
        AC_MSG_RESULT(no))
        LDFLAGS="${TMPLDFLAGS}"

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.

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?

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:

https://bugzilla.redhat.com/show_bug.cgi?id=955147#c2

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

Created attachment 741989 [details]
fix-gtk-doc-issue-with-hardened-build.patch

Patch fixes the issue locally, but apparently not on the buildsystem.  We really do want the redhat-rpm-config bug 892837 fixed.

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.

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

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!

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

NetworkManager-0.9.8.1-4.git20130515.fc19,network-manager-applet-0.9.8.1-4.git20130514.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.8.1-4.git20130515.fc19,network-manager-applet-0.9.8.1-4.git20130514.fc19

Package NetworkManager-0.9.8.1-4.git20130515.fc19, network-manager-applet-0.9.8.1-4.git20130514.fc19:
* 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-0.9.8.1-4.git20130515.fc19 network-manager-applet-0.9.8.1-4.git20130514.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8509/NetworkManager-0.9.8.1-4.git20130515.fc19,network-manager-applet-0.9.8.1-4.git20130514.fc19
then log in and leave karma (feedback).

NetworkManager-0.9.8.1-4.git20130515.fc19, network-manager-applet-0.9.8.1-4.git20130514.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.