Skip to content

Instantly share code, notes, and snippets.

@anestisb

anestisb/grsecurity_pax_copperheados.md

Created August 14, 2016 04:42
Show Gist options
  • Save anestisb/215e6b46b8e4260535819a495cd5ef60 to your computer and use it in GitHub Desktop.
Save anestisb/215e6b46b8e4260535819a495cd5ef60 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
grsecurity_pax_copperheados.md

This is an overview of the usefulness of PaX/grsecurity features for CopperheadOS especially when taking into account the overlap of the access control features with SELinux and that the Nexus line will be entirely 64-bit ARM. Note that it's missing most of the unnamed features without configuration options tied to them. A grsecurity kernel also comes with lots of security bug fixes backported from master, adapted from lkml submissions that were ignored, etc.

Previously, CopperheadOS used ports of PaX to the 3.4 Android kernels used by the Nexus 5 and Galaxy S4. The plan was to start from there, backporting from the PaX stable patches as needed along with reimplementing the relevant pieces of grsecurity without actually applying an old patch and backporting to it.

This is no longer the case for the published releases now that devices have moved to 64-bit ARM (which is not supported by PaX / grsecurity yet) and both the PaX and grsecurity stable patches have become private. There are still PaX ports for testing purposes, but they're not in a good enough state to deploy them in production. A bit of this is also due to having lower standards than would be acceptable for a production OS in the early pre-alpha and alpha days of CopperheadOS.

The new short-term plan will be following along with the Kernel Self-Protection Project efforts along with implementing many of the missing pieces. In the long-term, using full grsecurity kernels is desired but it won't realistically happen until Android devices are able to use mainline kernels.

PaX

  • NOEXEC - not really meaningful anymore
  • PAGEEXEC - minor security benefits outside i386 (no signal handler call for NX violations)
  • SEGMEXEC - not relevant outside i386
  • EMUTRAMP - not needed
  • EMUSIGRT - not needed
  • MPROTECT - needs to be ported to AArch64 (does a fair bit more than the similar SELinux features)
  • MPROTECT_COMPAT - not needed
  • ELFRELOCS - not needed
  • ETEXECRELOCS - not needed
  • EMUPLT - not needed
  • DLRESOLVE - not needed
  • KERNEXEC - needs to be ported to AArch64 (PXN covers a subset of this but it's not the whole feature at all)
  • ASLR - see RANDMMAP
  • RANDKSTACK - needs to be ported to ARM and AArch64
  • RANDUSTACK - see RANDMMAP
  • RANDMMAP - needs to be ported to AArch64
  • MEMORY_SANITIZE - wanted
  • MEMORY_STACKLEAK - wanted
  • MEMORY_STRUCTLEAK - wanted
  • MEMORY_UDEREF - needs to be ported to AArch64 for ARMv8.0 since PAN comes with ARMv8.1 (see http://www.openwall.com/lists/kernel-hardening/2016/08/12/11)
  • REFCOUNT - needs to be ported to AArch64
  • CONSTIFY_PLUGIN - wanted
  • USERCOPY - partial implementation landed upstream as HARDENED_USERCOPY (no slab whitelisting yet)
  • SIZE_OVERFLOW - wanted, but likely only in debugging mode for a long time
  • LATENT_ENTROPY - not really needed, already have hardware random number generators
  • RAP - needs to be ported to AArch64 followed by lots of fixes for undefined calls
  • PaX stack gap - significance unknown since Android doesn't use the brk heap (note: the old implementation caused issues with ART but it's likely not an issue with the current implementation in PaX)
  • DEBUG_LIST hardening - wanted
  • slab allocator hardening (separate from USERCOPY)

+ the CopperheadOS extension for group-based PaX exceptions used by the app integration (as permissions granted based on an exception database + automated checks)

grsecurity

integrated

  • PERF_HARDEN - local kernel attack surface reduction, landed as perf_event_paranoid=3 by default in AOSP with SELinux policy permitting it to be toggled off by the ADB shell user (disabled by default) via a system property
  • DENYUSB - physical attack surface reduction, tied to screen lock state by default (setting exposes on, off, dynamic)
  • DEVICE_SIDECHANNEL - closes time-based sidechannels for device types

wanted

  • further DEBUG_LIST hardening in addition to what PaX does
  • PROC_MEMMAP - likely won't break anything
  • HIDESYM - have kptr_restrict, but this plugs additional holes (could just extract them)
  • RANDSTRUCT - Unique kernel per-device and also per-version means it wouldn't be useless, but it could be a lot more useful if there were different release channels per-device. Could rebuild only the kernel (very quick for Android) to save time, although incremental builds are sketchy.
  • KSTACKOVERFLOW - a feature based on this is slowly being developed upstream, but it will be a while before it's ready even in mainline
  • RWXMAP_LOG - in userdebug builds

IDS-related

Features that would likely be useful to a theoretical IDS but not otherwise since there's no system administrator to review logs and it's not particularly useful for debugging other than the RWXMAP_LOG feature.

  • all of the auditing features
  • PROC_IPADDR

undecided

  • SETXID - would fix the issue in Android's libc, but only the base system uses this and it's unlikely that this would fix any vulnerabilities - unlike a traditional distribution
  • TPE - some functionality is covered by SELinux, but not all - the main issue is compatibility
  • BRUTE - Android doesn't use suid/sgid binaries and spawning processes is almost all done via init/zygote with init already throttling respawning to some extent
  • NO_SIMULT_CONNECT - TCP simultaneous connect can be used by WebRTC, need to determine the importance
  • PTRACE_READEXEC
  • HARDEN_PTRACE - more than SELinux can do but new kernels have stackable ptrace_scope based on it
  • FIFO - not sure if Android apps can even use FIFOs, should investigate this
  • HARDEN_TTY

leaning against

  • socket groups - Android already has a similar kernel feature for the network permission
  • SYMLINKOWN - not really any use case where it wouldn't break everything
  • KMEM - likely redundant due to SELinux
  • IO - likely redundant due to SELinux
  • RAND_THREADSTACK - similar mitigation can be done in libc

incompatible and/or unnecessary

  • all of the chroot hardening features - Android doesn't use chroots for anything and there are better ways of doing isolation than chroots when starting from scratch
  • KERN_LOCKOUT - Android uses panic_on_oops
  • RBAC - not currently flexible enough, and Android is far too heavily invested in SELinux already
  • JIT_HARDEN - not ever going to be enabling the BPF JIT engine
  • MODHARDEN - Nexus devices do not use kernel modules
  • DMESG - implemented via dmesg_restrict and SELinux already
  • LINK - available via fs.protected_{hardlinks,symlinks}
  • BLACKHOLE - netfilter is always used anyway
  • SYSFS_RESTRICT - not flexible enough, and the SELinux policy for /sys is already very strict
  • HARDEN_IPC - Android doesn't enable System V IPC
  • VM86 - not going to be supporting any 32-bit x86 devices, or really any more 32-bit devices at all
  • ROFS - would be incompatible with external storage, and wouldn't provide much value since mount access is extremely limited while the kernel attack surface is huge
  • PROC, PROC_{USER,USERGROUP}, PROC_ADD - already have hidepid and SELinux for this. For PROC_ADD, Android already removes proc access from untrusted apps but finer-grained restrictions would be nice:
    • buddyinfo - todo
    • bus - todo
    • bus/pci - todo
    • cmdline - todo (but already root:radio 440)
    • config.gz - not present
    • devices - todo
    • interrupts - done
    • iomem - todo (but already root:root 400)
    • ioports - todo
    • kcore - not present
    • pagetypeinfo - todo
    • sched_debug - todo
    • slabinfo - todo
    • stat - done
    • timer_list - done
    • timer_stats - done
    • vmstat - done
    • zoneinfo - done
    • etc. (likely missing a few for now)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment