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.
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.
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 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 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.
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.
Is CopperheadOS using grsec or something derived from it?
On Thu, Apr 27, 2017 at 7:12 PM, Carsten Mattner carstenmattner@gmail.com wrote:
Is CopperheadOS using grsec or something derived from it?
Found the technical details, it seems to be select grsec features ported to AOSP but not a full port of grsec, which together with the other hardening looks reasonable since it's a whole system/distro approach.
On Thu, 2017-04-27 at 19:12 +0000, Carsten Mattner wrote:
Is CopperheadOS using grsec or something derived from it?
It starts from the baseline provided by Google and ports features from PaX and grsecurity as needed to the kernels. It used to use a full PaX port on ARM devices but that hasn't made sense for quite some time.
Android is much a different target. CopperheadOS is starting from a base system that's already quite hardened. PaX / grsecurity kernel self protection features are applicable to Android but the bulk of them don't support arm64 in grsecurity at the moment so it's no use beyond as a source for porting / inspiration. The features that landed upstream ended up being ported to arm64. The grsecurity test patches becoming private has no impact on CopperheadOS. There's a significant indirect impact in that the source of 95% of Linux kernel security research / innovations is now no longer publicly available. KSPP no longer has an incredible source to copy ideas and code from and neither do we.
grsecurity RBAC and all but a few of the miscellaneous features aren't relevant to Android. It already has the baseline per-user, per-app uid/gid separation reinforced with a full system SELinux policy that's far beyond what RHEL / Fedora provide, since there's a well-defined base system (no system administrator choosing packages / configuration) and a well-defined app sandbox for all third party code. Devices handle their drivers and hardware-specific services/libraries via device-specific policy extensions. For example, SELinux ioctl filtering is used for kernel attack surface reduction by whitelisting ioctl commands per- device including whitelisting only the set of GPU driver ioctl commands used by the device in practice. They're also making increasingly good use of seccomp-bpf.
Even some of the most basic security features like full verified boot for the whole OS and always enabled encryption are pipe dreams for traditional distributions. Android's linker doesn't support non-PIE and text relocations are only supported for legacy API level 32-bit apps. Full RELRO, strong SSP and _FORTIFY_SOURCE=2 (beyond what glibc provides) are globally enabled.
The AOSP kernels are very minimal, i.e. no modules enabled and only a small set of drivers, etc. needed for the platform. Features like System V IPC and now AIO aren't enabled. Google already has KSPP features backported and enabled in their LTS kernels like HARDENED_USERCOPY (incomplete KSPP implementation of PaX USERCOPY), __ro_after_init (incomplete KSPP implementation of PaX __read_only) and PAN (UDEREF equivalent) emulation for ARM and ARMv8.0 where PAN isn't yet available. They also have kernel security features that were rejected upstream like perf_event_paranoid=3 which we upstreamed to AOSP.
In addition to that much different starting point, CopperheadOS also has full control of the entire base system. There's a unified build system and all of the sources are in one tree like a *BSD OS. It's so much different than trying to deal with bringing desktop Linux security on par with 2008 security standards, which is still so far away as a goal. One day perhaps flatpak / wayland will have caught up to providing a basic security model for desktop Linux and some day Arch will finally get PIE enabled by default but all of those kind of things are already provided by the baseline OS that CopperheadOS starts from.
On 04/27/2017 01:19 PM, Daniel Micay via arch-general wrote:
The PaX and grsecurity patches are no longer going to be public, so official support in Arch Linux has ended:
this is highly disappointing but not completely unexpected. thanks for your work all this time.
arch-general@lists.archlinux.org