[arch-dev-public] providing grsecurity in [community]
danielmicay at gmail.com
Fri Apr 18 05:26:40 EDT 2014
On 18/04/14 04:29 AM, henning mueller wrote:
> 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 , wrote an
> utility to set PaX flags  and host a repository for binary
> grsecurity packages . 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
> 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 . For a clean grsecurity
> integration, any flags on [core], [extra] and [community] should be
> set before releasing linux-grsec in [community].
By leaving it disabled, I mean enabling the soft mode compilation option
and having it disabled out-of-the-box. The PaX features will still be
compiled in to the kernel. A user will still be able to install the
linux-pax-flags package from the AUR and disable soft mode via the
sysctl flag. As far as I can tell, it's also possible to deal with PaX
exceptions entirely via an RBAC profile, so shipping a default-enabled
RBAC profile would be an alternative.
Even with PaX in soft mode, grsecurity comes with a significant amount
of kernel hardening, miscellaneous features (like auditing), and of
course the RBAC implementation which fills the gap left by the removal
of AppArmor/TOMOYO support from the [core] kernel.
In my opinion, the RBAC support is the most significant feature in the
context of Arch Linux, where no other MAC solution has caught on. I
don't think SELinux is a good fit due to the complexity, opaque
configuration and necessary patches. The path-based policy files used in
AppArmor/TOMOYO are great, but RBAC provides more flexibility and
resolving the paths to inodes before enforcement prevents the link-based
>> 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.)
I don't think there's an advantage to using install scripts rather than
the PKGBUILD itself. Pacman can learn to preserve extended attributes,
and it's much cleaner for this to be a tracked attribute of the package
rather than an ad-hoc hack.
Realistically, grsecurity is going to need a significant userbase (via
pkgstats) before a convincing argument can be made that this is
something Arch's packages should support. I don't think an AUR package
with 43 votes is anywhere close to enough proof that this is actually
going to see widespread usage.
Moving it to the repositories and providing a good out-of-the-box
experience is what needs to happen for this to gain the critical mass of
users (including other developers / trusted users) required to really
integrate it with the distribution.
I think the linux-pax-flags package can fill the gap until there's
either enough interest to maintain the flags across many packages, or
another solution like using RBAC is put in place.
> 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'm aware that you've spent a long time maintaining the package, and I'm
thankful for the hard work you've put into it. However, I have a
different view on how the packaging should be done. I want switching
from the linux package to linux-grsec to be a painless experience
without any breakage. After booting into a working grsecurity
environment, users can tighten up the sysctl knobs to their liking and
begin setting grsec_lock=1 if they desire.
At the moment, booting into the grsecurity kernel starts off users in an
environment where many things like containers, profiling (perf), network
bandwidth displays, etc. no longer work. I realize that starting from
everything forbidden and building a whitelist is a nice ideal, but
booting into an install where the web browser can't be started and many
of your services fail to start is enough to drive most users away from
> 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 . 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.
There are a important few packages already using PIE like Chromium and
OpenSSH, although this is likely because the projects are
security-focused and set this in their build system.
> Best regards,
>  https://aur.archlinux.org/packages/linux-grsec
>  https://github.com/nning/linux-pax-flags
>  https://arsch.orgizm.net
>  https://bbs.archlinux.org/viewtopic.php?id=172955
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the arch-dev-public