Gentoo Archives: gentoo-dev

From: "Anthony G. Basile" <blueness@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Regarding the State of PaX in the tree
Date: Mon, 16 Apr 2018 12:21:00
In Reply to: Re: [gentoo-dev] Regarding the State of PaX in the tree by Ulrich Mueller
1 On 4/16/18 3:22 AM, Ulrich Mueller wrote:
2 >>>>>> On Mon, 16 Apr 2018, Michał Górny wrote:
3 >
4 >> W dniu nie, 15.04.2018 o godzinie 20∶04 -0400, użytkownik
5 >> Anthony G. Basile napisał:
6 >>> The question then is, do we remove all this code? As thing stands,
7 >>> its just lint that serves no current purpose, so removing it would
8 >>> clean things up. The disadvantage is it would be a pita to ever
9 >>> restore it if we ever wanted it back. While upstream doesn't
10 >>> provide their patch for free, some users/companies can purchase the
11 >>> grsecurity patches and still use a custom hardened-sources kernel
12 >>> with Gentoo. But since we haven't been able to test the pax
13 >>> markings/custom patches in about a year, its hard to say how useful
14 >>> that code might still be.
15 >
16 > For Emacs, hardened support was quite a headache in the past, due to
17 > its unexec mechanism; see bugs 285778, 411439, 426394, 456970, 497498,
18 > 515122, 529172, their duplicates, and the upstream bugs linked from
19 > them. We cannot safely assume that any new (hardened kernel, or Emacs)
20 > version will work out of the box. Therefore, I am inclined to either
21 > remove the pax_kernel flag from my ebuilds, or to package.use.mask it
22 > at least, in order to make clear that this is no longer a supported
23 > configuration.
24 >
26 I was thinking particularly of emacs when I wrote this. So now not only
27 do we have those headaches, but no way to maintain them properly. For
28 emacs, I would just remove the pax stuff entirely and if
29 hardened-sources ever comes back, we would then deal accordingly.
31 >> One thing Hardened project should do is make a clear statement to
32 >> other developers -- i.e. indicate whether I should CC hardened@ when
33 >> someone has PaX problems and doesn't provide a patch, or just close
34 >> the bug saying that we can't solve it without a patch.
35 >
36 > I would even go one step further and tell people to sort things out
37 > with upstream. First, because I cannot reasonably upstream patches for
38 > an unsupported configuration that I cannot test. Second, since they
39 > have purchased the grsecurity patches, they should also ask grsecurity
40 > for support. Why should I as an unpaid volunteer spend my time on it?
41 >
43 This pretty much sums up my sentiment. I want to add here that I'm
44 upset with upstream's decision. For years we fixed many userland
45 programs that would otherwise have remained useless with their
46 hardening. I also worked to move the PaX flags from the elf program
47 headers (where it sometimes broke stuff) to the much safer xattrs.
48 benefited from all this work and then threw us under the
49 bus in their fight with whoever was abusing the license. Most unfair.
51 > Ulrich
52 >
55 --
56 Anthony G. Basile, Ph.D.
57 Gentoo Linux Developer [Hardened]
58 E-Mail : blueness@g.o
59 GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
60 GnuPG ID : F52D4BBA