| 1 |
W dniu nie, 15.04.2018 o godzinie 20∶04 -0400, użytkownik Anthony G. |
| 2 |
Basile napisał: |
| 3 |
> Hi everyone, |
| 4 |
> |
| 5 |
> Magnus (aka Zorry) and I have been talking about what to do with PaX in |
| 6 |
> the Gentoo tree. A year ago, grsecurity.net upstream stopped providing |
| 7 |
> open versions of their patches to the community and this basically |
| 8 |
> brought an end to sys-kernel/hardened-sources. I waited a while before |
| 9 |
> masking the package in the hope that upstream might reconsider. There |
| 10 |
> were also some forks but I didn't have much confidence in them. I'm not |
| 11 |
> sure that any of these forks have been able to keep up past |
| 12 |
> meltdown/specter. |
| 13 |
> |
| 14 |
> It may be time to remove sys-kernel/hardened-sources completely from the |
| 15 |
> tree. Removing the package is easy, but the issue is there is a lot of |
| 16 |
> machinery in the tree that revolves around supporting a PaX kernel. |
| 17 |
> This involves things like setting PaX flags on some executables either |
| 18 |
> by touching the ELF program headers or the file's extended attributes, |
| 19 |
> or applying custom patches. |
| 20 |
> |
| 21 |
> The question then is, do we remove all this code? As thing stands, its |
| 22 |
> just lint that serves no current purpose, so removing it would clean |
| 23 |
> things up. The disadvantage is it would be a pita to ever restore it if |
| 24 |
> we ever wanted it back. While upstream doesn't provide their patch for |
| 25 |
> free, some users/companies can purchase the grsecurity patches and still |
| 26 |
> use a custom hardened-sources kernel with Gentoo. But since we haven't |
| 27 |
> been able to test the pax markings/custom patches in about a year, its |
| 28 |
> hard to say how useful that code might still be. |
| 29 |
> |
| 30 |
|
| 31 |
I'd dare say keeping pax-marking in ebuilds doesn't harm, at least |
| 32 |
as long as we don't get reports that it's broken altogether. |
| 33 |
|
| 34 |
It's not like most of us has been able to test it anyway. The only pax- |
| 35 |
marks ever added to my ebuilds were by patches supplied by people |
| 36 |
actually using those kernels. In this context, not much has changed for |
| 37 |
most of our developers (i.e. 'can test' and 'will test' are two |
| 38 |
different things). |
| 39 |
|
| 40 |
One thing Hardened project should do is make a clear statement to other |
| 41 |
developers -- i.e. indicate whether I should CC hardened@ when someone |
| 42 |
has PaX problems and doesn't provide a patch, or just close the bug |
| 43 |
saying that we can't solve it without a patch. |
| 44 |
|
| 45 |
-- |
| 46 |
Best regards, |
| 47 |
Michał Górny |
Archives