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

[Daniel Micay]

On Thu, 2017-04-27 at 19:11 +0000, Carsten Mattner wrote:
> This is an undesirable situation for users, but I want to offer a
> positive outlook on this. Ever since KSPP started, some of the
> dynamics started to shift and I wager that closing off grsec will
> motivate more users and developers to consider supporting efforts that
> are in mainline linux. Short-term this is a problem and may require
> relying and hoping 4.9-lts-grsec will be available and functioning.
> When Bitkeeper licensing was revoked from the community, it didn't
> take long for git to emerge. I see a similar pattern and high
> potential for repetition of the same dynamics here. No grsec will
> force people to either subscribe ala RHEL and hope spender is able to
> fulfill his end of the contract or supporting KSPP and seamless LSM
> integration in major distro packages.

It's primarily not a technical issue, it's a political ones. As part
landing mitigations upstream, they end up being watered down into
slower, incomplete and/or weaker implementations. Lots has been outright
rejected. Software implementations of SMEP and SMAP are not happening
for i386 and x86_64. Proper slab sanitization was rejected. Proper page
sanitization was rejected. RAP and SIZE_OVERFLOW upstream are pipe
dreams. The REFCOUNT mitigation was rejected and is going to need to be
done as opt-in, but they also blocked an efficient implementation like
PaX and opt-in usage was rejected in the network stack, etc. due to the
performance cost of their crappier implementation. A new refcount_t
implementation may land, but there are a lot of politics involved and
landing a migration from atomic_t to refcount_t across the kernel is
going to be insanely slow and difficult. It has to be submitted bit by
bit to different maintainers... and that's only the tip of the iceberg
for these mitigations.

It's realistically going to take 5+ years for KSPP to land everything
other than RAP and SIZE_OVERFLOW and that's assuming it's extremely
successful and the political issues are overcome. UDEREF/KERNEXEC will
never land in their entirety and PaX and grsecurity are quickly moving
targets. RAP didn't exist until recently, and it's now the flagship
mitigation they offer. KERNSEAL/STRUCTGUARD won't have public code to
copy... and neither will all of the other new stuff. No one else is
doing compelling new kernel security research... so what happens once
there's no longer public code to copy? It's literally a copy-paste job
right now with bikeshedding of naming and kernel politics, and yet it's
still going poorly. KSPP is quite useful and is improving things, sure.
It's a joke to claim that it's going to be comparable to grsecurity
though.

> I must admit that spender may have started a process that will result
> in arriving quicker at mainline kernel having a comparable set of
> protections. Because as long as grsec was there and offered for
> relatively recent kernels, there wasn't much motivation or arguments
> to make to support a mainline reimplementation.
> 
> I believe this will light a fire under KSPP and related community
> driven projects.

I can't see it going any faster than it already is, which is slow
progress towards landing some things, with lots of setbacks and
crippling of the features to make them acceptable upstream. I don't
think there's any hope of landing mitigations like SIZE_OVERFLOW and RAP
any time in the near future. RAP requires sweeping fixes of undefined
behavior across the kernel, along with changes to calls/returns in all
of the assembly code. SIZE_OVERFLOW is similar, but also requires many
fixes of non-bugs. The only changes that have been successful landed
upstream are those that are quite contained, or bits and pieces of ones
that make wider changes in areas where the maintainers are active and
see the value of it. Familiarity with what's actually happening and has
happened already is needed to make any useful predictions about it.

> I faintly remember when there was OpenGrsec because grsec was dead or
> zombie but that was at least a decade ago and my memory is probably
> incomplete.

I can't find anything about that via searching for it. The grsecurity
patches are also a lot different in terms of what they contain now
compared to a decade ago. PaX started from NX emulation, inventing ASLR
and other userspace mitigations but then ended up being focused on
kernel self-protection and grsecurity similarly has a much different
focus than it did in the past. They're much bigger today and they have a
lot of complex, arcane code for architecture-specific mitigations.

> I mean some grsec users might consider fleeing to HardenedBSD since
> they provide a whole system like Hardened Gentoo, especially those
> using grsec on hosting servers where the availability of jails,
> capsicum, zfs, dtrace, ports and hardenedbsd may have already looked
> enticing.

HardenedBSD doesn't provide most of the grsecurity mitigations,
including some of the most important / strongest mitigations like RAP.
-------------- 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/c56cbb43/attachment.asc>