[arch-dev-public] Proposal: enabling full ASLR on x86_64 via hardening-wrapper

[Daniel Micay]

On 31/12/14 04:47 AM, Pierre Schmitz wrote:
> Am 26.12.2014 01:56, schrieb Allan McRae:
>> I am not in favour of using the hardening script because I don't find it
>> adheres to what we consider KISS.  Our build system is supposed to be
>> simple and entirely transparent when looking at the PKGBUILD and default
>> makepkg.conf.  Any user can run "abs" and "makepkg" and get (roughly)
>> the same package.
> 
> I agree, using such hacks kind of violates the kiss principle and our
> policy to follow upstream and don't patch or fork. I suggest to revistd
> this proposal once the needed changes are available upstream.

It's not necessarily going to land upstream. The fact that it can be
done without changes to GCC via build systems or hardening scripts is
the main reason it has been rejected in the past.

On a package-by-package basis, carrying out-of-tree patches for missing
SSP, RELRO and/or _FORTIFY_SOURCE is a lot less simple than simply
adding makedepends=(hardening-wrapper). Lack of full ASLR in a package
with a prominent attack surface is a higher priority bug than the other
flags, but since it's a problem nearly across the board there's little
point in filing them.

I gave up on doing this manually almost as soon as I started:

https://wiki.archlinux.org/index.php/DeveloperWiki:Security#Packages_not_respecting_flags

If I could I would just write a high latency version of
hardening-wrapper where it files a bug when CFLAGS / LDFLAGS wasn't
respected rather than just injecting the flags itself. Not going to work
thanks to stuff like autoconf.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20141231/dbf44107/attachment.bin>