Arch Linux improves package hardening

summerheat · Oct 24, 2016

On the arch-dev-public mailing list Allan McRae wrote today:

Hi all,

The results from the test-sec-flags [1] suite are in. Many thanks to
those that wrote this and those that submitted results. I'm not going
to list the summaries here, but the results show that at worst enabling
a bunch of security flags in our packages will have a <1% impact on
performance (and more likely a fraction of a percent).

That means we will add all of these to our default CFLAGS/LDFLAGS etc.
The changes are:

1) building gcc to enable PIE by default
2) add -z,now to LDFLAGS
3) and -fno-plt and -fstack-check to our CFLAGS

Adding PIE means that programs get loaded at a random address,
preventing an attacker from manipulating global data or hijacking
control by reusing code. Without this, ASLR is ineffective. Enabling
this by default in our compiler (there is a configure flag) means we
will need to rebuild all packages with static libraries (which should be
a fairly limited set).

Adding -z,now to LDFLAGS disables lazy loading. This means all function
symbols are loaded at startup (with minor performance hit), but that
means our RELRO support will make everything ro instead of some of the
things. Doing this enables us to use -fno-plt in our CFLAGS, which is a
run-time optimisation allowing faster use of libraries.

Adding -fstack-check to our CFLAGS guarantees stack overflows aren't
exploitable.

Note that any of these flags can be disabled in a PKGBUILD if really
needed... But if that is the case, bug reports should be filed.

Given an assumed lack of objection, I will enable the build flags in our
pacman.conf and rebuild gcc to enable pie and put them in [staging] at
the end of this week (what better way to celebrate Halloween). We will
need a new devtools release then too. Then the packages with static
libraries will need rebuilt.

After that, I would like to see [core] completely rebuilt, and audited
to ensure our CFLAGS/LDFLAGS are actually being used in the build.
Click to expand...

Definitely good news! So the performance impact of those security flags is smaller than often feared.

Anonfame1 · Oct 24, 2016

Wow- I can't believe they are actually going through with it! That is pure awesome... I had hoped but had a nagging fear it was prolly just talk. Arch has taken a number of strong steps towards security and in a short period of time- they were after all one of the last to have package signing. Then there's linux-grsec, paxd, hardening-wrapper, and now this...

That places Arch on the shortlist of (potentially) good security distros. Of course, much depends on the user and his/her setup, but the pieces are (almost) all there. About the only weakness Arch will have still is not having an easy MAC option available, though AppArmor (as im sure I've prolly beat to death around here) is very easy to have with a recompiled linux-grsec kernel. I dont include RBAC since it is a pain to maintain over the long haul

Log in or Sign up

Arch Linux improves package hardening

summerheat Registered Member

Anonfame1 Registered Member

Log in or Sign up

Arch Linux improves package hardening

summerheat Registered Member

Anonfame1 Registered Member

Useful Searches