Re: [gentoo-dev] Regarding the State of PaX in the tree
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 > >
Re: [gentoo-dev] Regarding the State of PaX in the tree
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 Description: OpenPGP digital signature
Re: [gentoo-dev] Regarding the State of PaX in the tree
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.
[gentoo-dev] Packages up for grabs: Enlightenment
Hello, everyone. The following packages are up for grabs due to the Enlightenment project being disbanded: app-doc/edox-data dev-libs/efl dev-python/python-efl media-libs/elementary media-libs/imlib2 media-plugins/emotion_generic_players media-plugins/evas_generic_loaders media-plugins/imlib2_loaders x11-misc/e16keyedit x11-misc/e16menuedit2 x11-plugins/epplets x11-terms/terminology x11-themes/ethemes x11-wm/enlightenment (+ enlightenment.eclass) The packages have a large number of bugs open. They are outdated, both in terms of releases and EAPI. The eclass needs either a major overhaul, or preferably removal as obsolete boilerplate. On the bright side, there is a certain interest in Enlightenment (including open PRs) from proxied maintainers, so the packages shouldn't have much trouble finding a new maintainer. -- Best regards, Michał Górny
Re: [gentoo-dev] Regarding the State of PaX in the tree
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.
Re: [gentoo-dev] Regarding the State of PaX in the tree
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: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Regarding the State of PaX in the tree
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
Re: [gentoo-dev] Regarding the State of PaX in the tree
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: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Regarding the State of PaX in the tree
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: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: [gentoo-dev] Regarding the State of PaX in the tree
* 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 Description: PGP signature
Re: [gentoo-dev] Regarding the State of PaX in the tree
> 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 pgp0RHuAa3UKg.pgp Description: PGP signature
Re: [gentoo-dev] Regarding the State of PaX in the tree
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
