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

[Daniel Micay]

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