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