Re: [arch-general] End of official PaX and grsecurity support in Arch Linux
It would be great if you can provide linux-hardened kernel with everything what KSPP has enabled by default. Even in AUR so you won't have to rebuild it constantly and random stack option would have more sense. Two questions: 1\. Do you think maintaining 4.9 lts grsec kernel would be doable until it gets EOL from upstream? Are there many incompatible changes with minor kernel releases? I heard gentoo (maybe debian?) are considering this. 2\. Why hidepid was removed? I saw "lack of time" comment but...there wasn't much to maintain as it worked flawles for long time. Thank you for your great effort in maintaining grsec for all that years. I'm looking forward to being your customer (Copperhead) when it will be avalaible overseas :) On On Thu, Apr 27, 2017 at 08:17 PM, Daniel Micay via arch-general <arch- general@archlinux.org> wrote: > 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. \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io
On Thu, 2017-04-27 at 20:45 +0000, Alexander Harrigan wrote:
It would be great if you can provide linux-hardened kernel with everything what KSPP has enabled by default. Even in AUR so you won't have to rebuild it constantly and random stack option would have more sense.
Two questions:
1\. Do you think maintaining 4.9 lts grsec kernel would be doable until it gets EOL from upstream?
That could be done, but it can't be called grsecurity or PaX anymore. There will be conflicts when applying the new patches. There will be real bugs that are caught by the mitigations and also some cases that are false positives or just benign issues that upstream doesn't consider to be a bug from features like SIZE_OVERFLOW. There is no longer an upstream (i.e. PaX and grsecurity) where these issues can be reported. For it to be officially packaged again, there needs to be a very competent upstream taking responsibility for everything as there was before. I don't really think it makes sense to track 4.9 until it dies. It's a dead end and new security features will be landing in mainline. I think it makes sense to have a linux-hardened package but I can't currently commit to doing that. I need to think about it over the next few days. It would also make sense to have a substantially stripped down fork, dropping everything that can be provided via upstream features, modern hardware (SMAP on Broadwell or later) or SELinux and just hoping that people work on having great SELinux support as an orthogonal project. I really don't have time for that though. It needs to be a collaborative effort, and I really do mean collaborative i.e. *multiple* people doing a substantial amount of difficult work and making hard decisions about what should be dropped to keep it maintainable. For example, some may see dropping UDEREF for x86_64 and just assuming SMAP is present to be too unfriendly to people with legacy hardware, but NOT doing that as much as possible means so much extra very complex code to maintain. I have no interest in maintaining code for legacy hardware that I don't use or being blocked by porting it to new kernel versions.
Are there many incompatible changes with minor kernel releases? I heard gentoo (maybe debian?) are considering this.
Plenty. It's very realistic to do that, but there's still work. The main issue is that there isn't going to be an end to upstream bugs and false positives being found, just fewer if it's frozen at 4.9 and destined to die off as it ages.
2\. Why hidepid was removed? I saw "lack of time" comment but...there wasn'tmuch to maintain as it worked flawles for long time.
A bug was reported where it caused problems booting. Multiple people stated that they hit it, so I believe that it's real. I don't have time to look into it and no one else was doing that, so I replaced it with documentation on doing it manually on the wiki: https://wiki.archlinux.org/index.php/Security#hidepid It was nice having the package, but if there's something broken and no one is addressing that I'm not going to keep it around.
participants (2)
-
Alexander Harrigan
-
Daniel Micay