Dhiru Kholia wrote:
1. Hardening flags should be turned on (by default) for all packages
which are at comparatively more risk of being exploited or which meet
some well-defined criteria (suggestions welcome).
Such criteria exist and are documented one click away from the page you
The current criteria are:
| 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
| · You can not use prelink on PIE enabled binaries, resulting in a
| slower startup time.
Dhiru Kholia wrote:
Such packages will typically include various system daemons, network
daemons and network enabled applications.
Lot of network daemons are already using PIE and RELRO (e.g. httpd,
MariaDB). So a natural question is why packages in same "network
daemons" class like PostgreSQL, Dovecot and MongoDB aren't being
Daemons are "long running", and therefore required to be hardened per
the first criterion. Network enabled applications match the fourth
criterion, so their maintainers "should consider enabling"
"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 only
be disabled for other packages at the maintainer's discretion provided
enough justification is given to FESCo" to be more appropriate.
FESCo decided on the criteria after a lot of discussion. As I understood
it the listed disadvantages were considered sufficient reason to not
make the hardening flags default across the whole distribution.
2. An alternate approach is to come up with an expanded list of
which should be hardened.
Since FESCo maintains a list, I suppose anyone can propose specific
programs to be added to the list, but it seems pointless to explicitly
list programs that are already covered by the first three criteria.