[arch-general] providing grsecurity in [community]

[henning mueller]

Hey,

I'm replying to a thread on arch-dev-public with the same subject, here.

I'm maintaining the linux-grsec PKGBUILD in the AUR [0], wrote an
utility to set PaX flags [1] and host a repository for binary
grsecurity packages [2]. Although I like the idea of further
integrating grsecurity into Arch Linux, I have some points to
criticize on the planning proposals of Daniel Micay.

> It also includes the PaX project to provide a much stronger 
> implementation of ASLR along with significant memory protections 
> for userspace. These features do break many packages, and require 
> setting flags on binaries when exceptions are necessary. I don't 
> want to place a burden on other packagers, so I plan on leaving
> the parts requiring integration with other packages disabled at
> first.

1. The very core of the grsecurity project is PaX. Without it, you
miss out on the most effective security features. Some contributing
linux-grsec users and me collected numerous binaries, which do not
work well with PaX and the according PaX features, which have to be
disabled in order to get them running. These are currently collected
in the linux-pax-flags utility [1]. For a clean grsecurity
integration, any flags on [core], [extra] and [community] should be
set before releasing linux-grsec in [community].

> It would have no impact on people not using it, since it would
> just be a very short string set in the `user.pax.flags` xattr key.
> For example, `setfattr -n user.pax.flags -v "mr" 
> "$pkgdir/usr/bin/foo"` to disable MPROTECT and RANDMMAP features 
> (on chromium, firefox, etc.).

2. I think, manually setting the flags with a setfattr call in the
PKGBUILDs is a bad solution, because it is error-prone. The Gentoo
(hardened) folks integrated a new function for marking binaries with
PaX flags into the ebuild environment. I would prefer a solution like
this for Arch, too.
A new PKGBUILD variable for PaX flags to be set after install() would
also be a good solution (like PAX_FLAGS=(usr/bin/firefox:mr).
(There is also a utility which supports xattr flags by the Gentoo
hardened folks named paxctl-ng.)

3. I do not know, what the policy is, here, but I would prefer to
maintain the PKGBUILD myself, if it gets included in [community]. At
least, I would have expected to be integrated in the discussion a
little more. I did the work on it since beginning of 2012 and run it
on several machines since then. I think, a message like "I will adopt your
package in [community]" is a little rude. The gradm package was
already deleted from the AUR. On the linux-pax-flags AUR package,
Daniel commented that I would have to change it to work according to
his plans.

I want to mention another step, that would be necessary for a decent
integration of grsecurity and full ASLR: The activation of PIE/PIC.
This has been discussed a little on the Arch Linux BBS [3]. Allan
stated that "If there is a good way to add it for x86_64, it will be
considered." Maybe it is possible to come up with a good way.

Best regards,
henning


[0] https://aur.archlinux.org/packages/linux-grsec
[1] https://github.com/nning/linux-pax-flags
[2] https://arsch.orgizm.net
[3] https://bbs.archlinux.org/viewtopic.php?id=172955