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 |
> |
25 |
|
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. |
30 |
|
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 |
> |
42 |
|
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 |
grsecurity.net benefited from all this work and then threw us under the |
49 |
bus in their fight with whoever was abusing the license. Most unfair. |
50 |
|
51 |
> Ulrich |
52 |
> |
53 |
|
54 |
|
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 |