Description

phenomenon

It would be great if this list could be expanded to include packages which are at comparatively more risk of being exploited (locally or remotely).

Such packages will typically include various system daemons, network daemons and network enabled applications.

(Implementing this will require changes to "Packaging Guidelines")

background analysis

Lot of network daemons are already using PIE and RELRO (e.g. httpd, MariaDB). So a natural question is why aren't packages in same "network daemons" class like PostgreSQL, Dovecot and MongoDB aren't being hardened?

implementation recommendation

I believe that hardening flags should be turned on (by default) for all packages which are at the risk of being exploited.

"Packaging Guidelines" say that "Other packages may enable the flags at the maintainer's discretion."

Thinking from a security perspective, I find "Hardening flags can be disabled for other packages at the maintainer's discretion provided enough justification is given to FESCo" to be more appropriate.

Change History

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.

I'm afraid "all packages which are at the risk of being exploited" is pretty broad and could include most everything.

You are right. I think packages which meet the criteria described in "comment:1" by mitr are suitable candidates for hardening.

However lot of packages (like PostgreSQL, Dovecot and MongoDB) which meet the criteria are still not being hardened. I am not sure if I should file bugs against individual packages *or* if FESCo can expand its list to include mentioned packages as well as similar packages (the latter option being more preferable).

I can work towards identifying more packages which could use hardening.

Note that RPM groups are almost entirely obsolete - they don't make a good guide here.

Yes, people in #fedora-devel told me the same. I am still looking for better ways to identify suitable packages. Suggestions are welcome!

However lot of packages (like PostgreSQL, Dovecot and MongoDB) which meet the criteria are still not being hardened. I am not sure if I should file bugs against individual packages *or* if FESCo can expand its list to include mentioned packages as well as similar packages (the latter option being more preferable).

If you think that some package meets the current criteria and it is not hardened yet, I think that filling a bug on the package cannot do any harm. So feel free to identify such packages and fill the bugs.

PIE disables use of prelink - so this is another performance impact on startup. On the other hand we should evaluate the impact of non-prelinked vs. prelinked startup time on modern computers, maybe it is no longer much relevant.

PIE disables use of prelink - so this is another performance impact on startup. On the other hand we should evaluate the impact of non-prelinked vs. prelinked startup time on modern computers, maybe it is no longer much relevant.

I'm not sure that in the study above the non-PIE binaries were prelinked or not. Also it would be more interesting to see the result for bigger desktop applications like LibreOffice?, Firefox, Evolution.

I'm not sure that in the study above the non-PIE binaries were prelinked or not. Also it would be more interesting to see the result for bigger desktop applications like LibreOffice?, Firefox, Evolution.

​http://en.wikipedia.org/wiki/Prelink mentions "Jakub Jelínek points out that position independent executables ignore prelinking on Red Hat Enterprise Linux and Fedora Core, and recommends that network and SUID programs be built PIE to facilitate a more secure environment."

I agree with your suggestion about measuring the impact of PIE on bigger Desktop applications. I will work on it (after the list is done).

In my opinion, any bugs reporting violation of packaging guidelines should be looked at in a prompt fashion.

Opening bugs against tons of packages (possibly) manually is a bit tedious. Ideas on how to solve this bit of the problem are welcome!

"hard data that demonstrate the impact, if any, in a situation relevant to Fedora (in particular, taking into account prelink as it is deployed by default) would be very welcome but is not a strict requirement".

Please see comment:10. In short, "... the average delay of a PIE application over a non-PIE application was significantly below perceivable threshold". Please note that "position independent executables ignore prelinking on Red Hat Enterprise Linux and Fedora Core", so the numbers presented in the report linked to in comment:10 should be good as they are).

Remember when Sun said "the network is the computer"? All packages handle untrusted user input and network input.

I'm strongly in favour of dropping prelink, and enabling hardening per default. Especially if the only price we pay is "a few seconds of waiting on initial loading of large applications". libreoffice is so slow to start, adding three, five or ten seconds isn't going to make a difference.

Short of that, I'd say any every daemon or service started through systemd/(x)inetd/ should enable hardening.

I'm strongly in favour of dropping prelink, and enabling hardening per default. Especially if the only price we pay is "a few seconds of waiting on initial loading of large applications". libreoffice is so slow to start, adding three, five or ten seconds isn't going to make a difference.

Well, the difference in loading time (for "large Desktop applications") does not even amount to a second (according to my tests which may be flawed).

In my opinion, any bugs reporting violation of packaging guidelines should be looked at in a prompt fashion.

I'm sorry to say I'm much more worried about unhandled crash reports (which may indicate possibly exploitable bugs) than missing hardening; that's not to say the bug shouldn't be handled - just that I don't think some kind of forceful prioritization of these bugs makes sense.

Opening bugs against tons of packages (possibly) manually is a bit tedious. Ideas on how to solve this bit of the problem are welcome!

There certainly are automated tools; is python-bugzilla the best one nowadays?

"hard data that demonstrate the impact, if any, in a situation relevant to Fedora (in particular, taking into account prelink as it is deployed by default) would be very welcome but is not a strict requirement".

Please see comment:10. In short, "... the average delay of a PIE application over a non-PIE application was significantly below perceivable threshold".

Please note that "position independent executables ignore prelinking on Red Hat Enterprise Linux and Fedora Core", so the numbers presented in the report linked to in comment:10 should be good as they are).

(FWIW, I'm looking for hard data as much preferable to opinions of the kind "I always disable $foo because it is slow". I don't currently have a specific threshold in mind that would sway me pro/con any decision.)

So in summary, your proposal is to keep the existing guidelines and enforce them better? I'm in any case fine with that.

Remember when Sun said "the network is the computer"? All packages handle untrusted user input and network input.

I'm strongly in favour of dropping prelink, and enabling hardening per default. Especially if the only price we pay is "a few seconds of waiting on initial loading of large applications".

That's the price for prelink (and btw. preferable overall latency is 0.1s), not for PIE, which is an ongoing cost (... for code located in the executable and not in libraries).

libreoffice is so slow to start, adding three, five or ten seconds isn't going to make a difference.

Actually libreoffice seems not to be getting slower, unlike the rest of the system... On my desktop even a cold start of libreoffice takes less than a second, which is curiously faster than gnome-documents as far as I can see (using a clock and my eyes, not at all scientific).

For the substance of the proposal, see my recent mail on fedora-devel about mutable/static ASLR - after thinking about this more I can't see prelink as a significant problem (... which is not making the decision easier - as argued above PIE is probably the decision that has larger cost).

In my opinion, any bugs reporting violation of packaging guidelines should be looked at in a prompt fashion.

I'm sorry to say I'm much more worried about unhandled crash reports (which may indicate possibly exploitable bugs) than missing hardening; that's not to say the bug shouldn't be handled - just that I don't think some kind of forceful prioritization of these bugs makes sense.

I should not have used the word "prompt". I meant to say that such bugs should be handled in a reasonable amount of time instead of just being ignored and moved from one release to another.

"hard data that demonstrate the impact, if any, in a situation relevant to Fedora (in particular, taking into account prelink as it is deployed by default) would be very welcome but is not a strict requirement".

Please see comment:10. In short, "... the average delay of a PIE application over a non-PIE application was significantly below perceivable threshold".