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

[Daniel Micay]

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.
-------------- 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/b8c5f9c1/attachment.asc>