Regarding the State of PaX in the tree

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Regarding the State of PaX in the tree

Anthony G. Basile
Hi everyone,

Magnus (aka Zorry) and I have been talking about what to do with PaX in
the Gentoo tree.  A year ago, grsecurity.net upstream stopped providing
open versions of their patches to the community and this basically
brought an end to sys-kernel/hardened-sources.  I waited a while before
masking the package in the hope that upstream might reconsider.  There
were also some forks but I didn't have much confidence in them.  I'm not
sure that any of these forks have been able to keep up past
meltdown/specter.

It may be time to remove sys-kernel/hardened-sources completely from the
tree.  Removing the package is easy, but the issue is there is a lot of
machinery in the tree that revolves around supporting a PaX kernel.
This involves things like setting PaX flags on some executables either
by touching the ELF program headers or the file's extended attributes,
or applying custom patches.

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.

I'm just emailing everyone to get advice.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

R0b0t1
On Sun, Apr 15, 2018 at 7:04 PM, Anthony G. Basile <[hidden email]> wrote:

> Hi everyone,
>
> Magnus (aka Zorry) and I have been talking about what to do with PaX in
> the Gentoo tree.  A year ago, grsecurity.net upstream stopped providing
> open versions of their patches to the community and this basically
> brought an end to sys-kernel/hardened-sources.  I waited a while before
> masking the package in the hope that upstream might reconsider.  There
> were also some forks but I didn't have much confidence in them.  I'm not
> sure that any of these forks have been able to keep up past
> meltdown/specter.
>
> It may be time to remove sys-kernel/hardened-sources completely from the
> tree.  Removing the package is easy, but the issue is there is a lot of
> machinery in the tree that revolves around supporting a PaX kernel.
> This involves things like setting PaX flags on some executables either
> by touching the ELF program headers or the file's extended attributes,
> or applying custom patches.
>
> 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.
>
> I'm just emailing everyone to get advice.
>

I retain hope that compatible features will be added to the kernel.
Consequently, I would appreciate if the machinery can be left. If it
becomes a maintenance burden in the future I suspect that would be a
good time to remove it.

Cheers,
     R0b0t1

Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Sam Jorna (wraeth)
In reply to this post by Anthony G. Basile
On Sun, Apr 15, 2018 at 08:04:43PM -0400, Anthony G. Basile wrote:
> 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.

Aside from potential breakage of pax-enabled systems due to lack of
(ability to perform) testing, is there any burden to keeping it?

Unless there's specific benefit to be had by removing the code, I'd be
inclined to keep it in-place to facilitate Gentoo users who do subscribe
to GRSecurity and use their patchset, granted with the disclaimer that
we can't test. Removing the machinery to support it would just drive
users to different platforms.

Alternatively, perhaps someone from GRSec could help maintain it, since
they would obviously be in a position to actually test. Though, I'm not
sure how viable it is to have someone maintaining functionality to
support a patchset that the majority of us cannot access...

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

signature.asc (875 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Michał Górny-5
In reply to this post by Anthony G. Basile
W dniu nie, 15.04.2018 o godzinie 20∶04 -0400, użytkownik Anthony G.
Basile napisał:

> Hi everyone,
>
> Magnus (aka Zorry) and I have been talking about what to do with PaX in
> the Gentoo tree.  A year ago, grsecurity.net upstream stopped providing
> open versions of their patches to the community and this basically
> brought an end to sys-kernel/hardened-sources.  I waited a while before
> masking the package in the hope that upstream might reconsider.  There
> were also some forks but I didn't have much confidence in them.  I'm not
> sure that any of these forks have been able to keep up past
> meltdown/specter.
>
> It may be time to remove sys-kernel/hardened-sources completely from the
> tree.  Removing the package is easy, but the issue is there is a lot of
> machinery in the tree that revolves around supporting a PaX kernel.
> This involves things like setting PaX flags on some executables either
> by touching the ELF program headers or the file's extended attributes,
> or applying custom patches.
>
> 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.
>

I'd dare say keeping pax-marking in ebuilds doesn't harm, at least
as long as we don't get reports that it's broken altogether.

It's not like most of us has been able to test it anyway.  The only pax-
marks ever added to my ebuilds were by patches supplied by people
actually using those kernels.  In this context, not much has changed for
most of our developers (i.e. 'can test' and 'will test' are two
different things).

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.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Ulrich Mueller-2
>>>>> 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.

> 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?

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Marc Schiffbauer
In reply to this post by Anthony G. Basile
* Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
> Hi everyone,

Hi Anthony,

I vote for keeping PaX Support as I am still using it and might be doing
so in the future.

Thanks ;)
-Marc

--
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
                     6E9E CA3E 7BF6 7F97 9BE5

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Hanno Böck-3
In reply to this post by Anthony G. Basile
Hi,

I honestly don't see how it would be feasible to maintain a feature
that the developers maintaining it have access to.

I get that this whole pax-thing embodies a huge part of Gentoo history
and it may feel hard for some to let it go. But things are how they are.

Regarding the fork states: I followed up on minipli's fork, which
tried to maintain newer patches of grsec for LTS kernels, but that
essentially stopped after KPTI/meltdown/retpoline. From what I know
there's no public grsec patch with kpti or any spectre fixes, thus I
would very much say you're safer these days with an upstream kernel.

I think the only realistic way this support can be upheld would be if
some people who have access to the grsec sources commit to making sure
that it is maintained.


There's also another question related to this: What's the future for
Gentoo hardened?
From what I can tell hardened consists of:
* the things that try to make it compatible with grsec/pax
  (more or less obsolete).
* things that are now in default profiles anyway (aslr, stack
  protector).
* things that probably should be in default profiles (relro, now linker
  flags)
* -fstack-check, which should eventually be replaced with
  -fstack-clash-protection (only available in future gcc's) and that
  should probably also go into default profiles.
* Furthermore hardened disables some useful features due to their
  incompatibility with pax (e.g. sanitizers).

So it's stuff that either is obsolete or probably should be a candidate
for main profiles. Maybe we should strive for "hardened-by-default".

--
Hanno Böck
https://hboeck.de/

mail/jabber: [hidden email]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Anthony G. Basile
In reply to this post by Marc Schiffbauer
On 4/16/18 4:05 AM, Marc Schiffbauer wrote:

> * Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
>> Hi everyone,
>
> Hi Anthony,
>
> I vote for keeping PaX Support as I am still using it and might be doing
> so in the future.
>
> Thanks ;)
> -Marc
>

How are you able to test?  Do you have your hands on the latest grsec
patches or are you using an old kernel.  Old at this point means one
year old.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Anthony G. Basile
In reply to this post by Ulrich Mueller-2
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    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Anthony G. Basile
In reply to this post by Hanno Böck-3
On 4/16/18 5:14 AM, Hanno Böck wrote:
> Hi,
>
> I honestly don't see how it would be feasible to maintain a feature
> that the developers maintaining it have access to.

I think you're missing a negation in there.  Point well taken though.


>
> I get that this whole pax-thing embodies a huge part of Gentoo history
> and it may feel hard for some to let it go. But things are how they are.

I agree, and we'll have it in our history if hardened-sources ever comes
back.  The only machinery we should keep is install-xattrs which grew
out of the integration of xattr PaX markings but is useful beyond just PaX.

>
> Regarding the fork states: I followed up on minipli's fork, which
> tried to maintain newer patches of grsec for LTS kernels, but that
> essentially stopped after KPTI/meltdown/retpoline. From what I know
> there's no public grsec patch with kpti or any spectre fixes, thus I
> would very much say you're safer these days with an upstream kernel.
>

Correct.  I would not use the old hardened-sources or minipli's fork on
any production server.

> I think the only realistic way this support can be upheld would be if
> some people who have access to the grsec sources commit to making sure
> that it is maintained.

Upstream has never responded to any email I sent them.  I had a brief
discussion with spender when the decision came down, and he gave me what
I interpreted as an "I'm sorry this is going to adversely affect you but
it has to be this way."

>
>
> There's also another question related to this: What's the future for
> Gentoo hardened?
> From what I can tell hardened consists of:
> * the things that try to make it compatible with grsec/pax
>   (more or less obsolete).
> * things that are now in default profiles anyway (aslr, stack
>   protector).
> * things that probably should be in default profiles (relro, now linker
>   flags)
> * -fstack-check, which should eventually be replaced with
>   -fstack-clash-protection (only available in future gcc's) and that
>   should probably also go into default profiles.
> * Furthermore hardened disables some useful features due to their
>   incompatibility with pax (e.g. sanitizers).
>
> So it's stuff that either is obsolete or probably should be a candidate
> for main profiles. Maybe we should strive for "hardened-by-default".
>

You're forgetting selinux.  Most of Zorry's work has made it into gcc
and is now being enabled by our default toolchain.  Some kernel features
have also been improved upstream.  With upstream carrying a lot of the
work we did, I think 'hardened-by-default' minus selinux should be the
goal of Gentoo.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Francesco Riosa-3

Il 16/04/2018 14:31, Anthony G. Basile ha scritto:
> On 4/16/18 5:14 AM, Hanno Böck wrote:
[snip]

>
>>
>> There's also another question related to this: What's the future for
>> Gentoo hardened?
>> From what I can tell hardened consists of:
>> * the things that try to make it compatible with grsec/pax
>>   (more or less obsolete).
>> * things that are now in default profiles anyway (aslr, stack
>>   protector).
>> * things that probably should be in default profiles (relro, now linker
>>   flags)
>> * -fstack-check, which should eventually be replaced with
>>   -fstack-clash-protection (only available in future gcc's) and that
>>   should probably also go into default profiles.
>> * Furthermore hardened disables some useful features due to their
>>   incompatibility with pax (e.g. sanitizers).
>>
>> So it's stuff that either is obsolete or probably should be a candidate
>> for main profiles. Maybe we should strive for "hardened-by-default".
>>
> You're forgetting selinux.  Most of Zorry's work has made it into gcc
> and is now being enabled by our default toolchain.  Some kernel features
> have also been improved upstream.  With upstream carrying a lot of the
> work we did, I think 'hardened-by-default' minus selinux should be the
> goal of Gentoo.
>
Hardened had strong impact in some workflows, surpassing 10%.
Overhead could be acceptable in some situation but unwanted in others,
main profiles are obscure and difficult to change for most.
For this reason I'd like to ask to carefully evaluate if a security
feature can be enabled without suddently change the behaviour (worse
performances) of a machine running Gentoo.
Instead it would be good to have a guide on how to further harden any
profile.
If the hardening at any cost argument wins however we MUST have a guide
on ho to disable at least the most impactful options.




Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Patrick McLean-3
In reply to this post by Anthony G. Basile
On 2018-04-16 05:12 AM, Anthony G. Basile wrote:

> On 4/16/18 4:05 AM, Marc Schiffbauer wrote:
>> * Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
>>> Hi everyone,
>>
>> Hi Anthony,
>>
>> I vote for keeping PaX Support as I am still using it and might be doing
>> so in the future.
>>
>> Thanks ;)
>> -Marc
>>
>
> How are you able to test?  Do you have your hands on the latest grsec
> patches or are you using an old kernel.  Old at this point means one
> year old.
>

I am able to test, we have access to the latest grsecurity kernels at my
employer, and we would very much prefer to keep the PaX markings around.

We (I work with several Gentoo developers) are actively testing all the
packages we use internally with newer kernels, and fixing anything that
breaks.

Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Toralf Förster-2
In reply to this post by Hanno Böck-3
On 04/16/2018 11:14 AM, Hanno Böck wrote:

> There's also another question related to this: What's the future for
> Gentoo hardened?
> From what I can tell hardened consists of:
> * the things that try to make it compatible with grsec/pax
>   (more or less obsolete).
> * things that are now in default profiles anyway (aslr, stack
>   protector).
> * things that probably should be in default profiles (relro, now linker
>   flags)
> * -fstack-check, which should eventually be replaced with
>   -fstack-clash-protection (only available in future gcc's) and that
>   should probably also go into default profiles.
> * Furthermore hardened disables some useful features due to their
>   incompatibility with pax (e.g. sanitizers).
Which let me wonder, what I would lose today by a switch from
17.0-hardened + USE-flags to 17.0/desktop/plasma at my KDE desktop?

--
Toralf
PGP 23217DA7 9B888F45



signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Jason Zaman
On Mon, Apr 16, 2018 at 07:53:07PM +0200, Toralf Förster wrote:

> On 04/16/2018 11:14 AM, Hanno Böck wrote:
> > There's also another question related to this: What's the future for
> > Gentoo hardened?
> > From what I can tell hardened consists of:
> > * the things that try to make it compatible with grsec/pax
> >   (more or less obsolete).
> > * things that are now in default profiles anyway (aslr, stack
> >   protector).
> > * things that probably should be in default profiles (relro, now linker
> >   flags)
> > * -fstack-check, which should eventually be replaced with
> >   -fstack-clash-protection (only available in future gcc's) and that
> >   should probably also go into default profiles.
> > * Furthermore hardened disables some useful features due to their
> >   incompatibility with pax (e.g. sanitizers).
>
> Which let me wonder, what I would lose today by a switch from
> 17.0-hardened + USE-flags to 17.0/desktop/plasma at my KDE desktop?

Right now, the main things you'd lose are bindnow and
fstack-protector-all vs fstack-protector-strong i think. But in the
future as new hardening stuff is added to the toolchains they will
likely be enabled in hardened before default too.

-- Jason
>
> --
> Toralf
> PGP 23217DA7 9B888F45
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Regarding the State of PaX in the tree

Marc Schiffbauer
In reply to this post by Anthony G. Basile
* Anthony G. Basile schrieb am 16.04.18 um 14:12 Uhr:

> On 4/16/18 4:05 AM, Marc Schiffbauer wrote:
> > * Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
> >> Hi everyone,
> >
> > Hi Anthony,
> >
> > I vote for keeping PaX Support as I am still using it and might be doing
> > so in the future.
> >
> > Thanks ;)
> > -Marc
> >
>
> How are you able to test?  Do you have your hands on the latest grsec
> patches or are you using an old kernel.  Old at this point means one
> year old.
Right now, I only have grsecurity-sources (4.9.74) but I may have access
to latest grsecurity patches later this year.

Gruß
-Marc

--
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
                     6E9E CA3E 7BF6 7F97 9BE5

signature.asc (849 bytes) Download Attachment