[arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay]

The PaX and grsecurity patches are no longer going to be public, so
official support in Arch Linux has ended:

https://grsecurity.net/passing_the_baton.php
https://grsecurity.net/passing_the_baton_faq.php

I'll be clearing out the AUR packages for PaX and grsecurity soon since
the current 4.10 patches are not accessible. Providing out-of-date
packages with known vulnerabilities and without the current set of
mitigations is infringing on how they want their trademarks used. If
people want to maintain forks, either a 4.9 LTS or porting it forward to
newer kernels, they'll need to make a new project with a new name rather
than using "PaX" or "grsecurity" as the naming. If it's serious and done
by people that know what they're doing, official support for it can be
considered. There are few people that are capable of truly taking over
maintenance of the whole patches and I expect that they won't have time
to do it. Don't be optimistic about this happening.

There are no viable alternatives to PaX and grsecurity. Their focus is
on kernel self-protection i.e. protecting the kernel from exploits, and
we don't have anything for users to migrate to from these. There are
plenty of alternatives to grsecurity RBAC but that's only a small
portion of what the patches provide. Any form of access control (whether
it's MAC, containers, uid/gid separation, ACLs, etc.) can be entirely
bypassed with a single kernel exploit, so the only good way to use other
MAC implementations like TOMOYO, AppArmor or SELinux was with
grsecurity. We don't actually provide official support for any of these
alternatives, but it's all little good without a hardened kernel anyway.

A small subset of the kernel self-protection features have landed
upstream as part of the Kernel Self Protection Project. The core/linux
package doesn't enable the bulk of these features, and it probably
doesn't make sense for it to turn everything on because a subset of them
 do have a significant performance cost. It would be possible to provide
a linux-hardened package doing that but it would only offer a tiny
portion of the kernel self-protection that grsecurity does. I may end up
doing that, along with enabling support for all of the LSMs, etc. there
but it's really not at all comparable to what has been lost. The LSMs
are also little good without people working on providing userspace
integration and policies for them.

There are no good answers here. It would be possible to maintain a fork
of grsecurity, especially if all kernel architectures other than x86_64
(and arm64, but it's not currently supported) were dropped along with
grsecurity RBAC and anything that has a proper equivalent upstream. i386
and armv7 can still be supported as userspace archs, since dropping them
as kernel archs is what would save most of the maintainance work and
would eliminate a bunch of complex code only currently fully understood
by the PaX and grsecurity authors. It might also make sense to start
dropping support for old CPUs, beyond just only supporting 64-bit
kernels. Intel Broadwell and later provide SMAP and there's also SMEP,
so those could be used as substitutes for UDEREF and that portion of the
KERNEXEC feature.

The problem is that there aren't capable people with the time and
willingness to dedicate a huge amount of their time to a volunteer
project without pay. I already maintain/develop hardened Android LTS
kernels as a significant but overall quite small part of CopperheadOS.
It's not comparable to this because it's my job. I spend far more than
40 hours a week on CopperheadOS, and it's actually quite a relief to not
need to worry about maintaining PaX and grsecurity for Arch Linux
anymore especially since I had to do it on my own. I've been aware that
the test patches becoming private was a very real possibility even
before spender started talking about it on IRC weeks ago, so it's really
not a surprise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170427/d43c53f3/attachment.asc>