Summary: | net-libs/nodejs-12.10.0 on a pax-enabled (grsecurity) kernel - #FailureMessage Object: 0x72d4f41ff200/bin/sh: line 1: 17291 Illegal instruction ".../work/node-v12.10.0/out/Release/mkcodecache" ".../work/node-v12.10.0/out/Release/obj/gen/node_code_cach | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Attila Tóth <atoth> |
Component: | Hardened | Assignee: | William Hubbs <williamh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jer |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=735832 https://bugs.gentoo.org/show_bug.cgi?id=903916 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
node-v12.8.1-mknodecache-node_mksnapshot.patch
Add actions to pax mark needed files mksnapshot_paxmark.patch Updated patch to pax mark needed files nodejs-16.4.2-paxmarking.patch nodejs-18.0.0-paxmarking.patch nodejs-18.3.0-paxmarking.patch nodejs-20.3.0-paxmarking.patch |
Description
Attila Tóth
2019-09-11 20:05:56 UTC
Created attachment 589696 [details, diff]
node-v12.8.1-mknodecache-node_mksnapshot.patch
Proposed patch to take care of pax-marking compile-time binaries. Works for me.
We allready mark it in the ebuild but do we need new one? We have turn of default pax marking in all profiles and we have no ways to test it when we don't have access to pax/grsec. If we need a new take a look on qtwebengine how it is done there. (In reply to Magnus Granberg from comment #2) > We allready mark it in the ebuild but do we need new one? > We have turn of default pax marking in all profiles and we have > no ways to test it when we don't have access to pax/grsec. > If we need a new take a look on qtwebengine how it is done there. The ebuild marks the build-time executable "mksnapshot". One may simply issue make for that executable and take care of the marking in the ebuild. While these two new build-time executables are different (node_mksnapshot, mkcodecache) and showed up only recently (in nodejs-12.x). I could find a way to mark them the same way as it works for mksnapshot. The current qtwebengine build is a little different, this nodejs thing is close to a previous version (qtwebengine-5.6.1). I'm really afraid, that I will be left alone eventually with these problems because of the lack of people still having access to grsecurity. I may not be able to take care of these forever. However I felt, that I don't want to keep this patch for myself and others might still make use of it just in case... I can reproduce this issue on a 4.14.142 grsecurity kernel, but the patch does not fix it for me. (In reply to Patrick McLean from comment #4) > I can reproduce this issue on a 4.14.142 grsecurity kernel, but the patch > does not fix it for me. I have access to beta patches. I'll try to retest it with the latest beta. (In reply to Attila Tóth from comment #5) > (In reply to Patrick McLean from comment #4) > > I can reproduce this issue on a 4.14.142 grsecurity kernel, but the patch > > does not fix it for me. > > I have access to beta patches. I'll try to retest it with the latest beta. The situation is the same for net-libs/openjs-12.11.0 from the anarchy overlay. It fails without the patch. The proposed patch solves the problem on my systems running grsec beta (5.2.17-201909242038). This is not the latest, because there is a fresh beta from yesterday I will only be able to use later today or tomorrow. But I would expect the same. The patch faile to applay to nodejs-6-16-2 (In reply to Attila Tóth from comment #6) > (In reply to Attila Tóth from comment #5) > > (In reply to Patrick McLean from comment #4) > > > I can reproduce this issue on a 4.14.142 grsecurity kernel, but the patch > > > does not fix it for me. > > > > I have access to beta patches. I'll try to retest it with the latest beta. > > The situation is the same for net-libs/openjs-12.11.0 from the anarchy > overlay. It fails without the patch. The proposed patch solves the problem > on my systems running grsec beta (5.2.17-201909242038). This is not the > latest, because there is a fresh beta from yesterday I will only be able to > use later today or tomorrow. But I would expect the same. My observations are still the same for nodejs-13.0.1 vs grsec-3.1-5.3.8-201911041113. The attached patch takes care of the issue. Created attachment 595918 [details, diff]
Add actions to pax mark needed files
Smaller patch, testing needed.
no need to pax mark in src_compile
(In reply to Magnus Granberg from comment #9) > Created attachment 595918 [details, diff] [details, diff] > Add actions to pax mark needed files > > Smaller patch, testing needed. > no need to pax mark in src_compile Patch tested right, but I haven't modified src_compile. Thx: Dw. Jer is it okay to applay the patch as what is don in qtwebengine? The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d3b53be221b0288c4eb5155ad52fa8f27bda083d commit d3b53be221b0288c4eb5155ad52fa8f27bda083d Author: Magnus Granberg <zorry@gentoo.org> AuthorDate: 2019-11-27 21:28:02 +0000 Commit: Magnus Granberg <zorry@gentoo.org> CommitDate: 2019-11-27 21:29:14 +0000 net-libs/nodejs: Fix build on PAX enable kernel (bug 694100) We need to disable mprotect on two bins when we compile bug 694100. Closes: https://bugs.gentoo.org/694100 Reported-by: Attila Tóth <atoth@atoth.sote.hu> Co-developed-by: Attila Tóth <atoth@atoth.sote.hu> Signed-off-by: Magnus Granberg <zorry@gentoo.org> Package-Manager: Portage-2.3.76, Repoman-2.3.16 .../nodejs/files/nodejs-13.2.0-paxmarking.patch | 71 ++++++++++++++++++++++ net-libs/nodejs/metadata.xml | 1 + net-libs/nodejs/nodejs-13.2.0.ebuild | 8 ++- net-libs/nodejs/nodejs-99999999.ebuild | 8 ++- 4 files changed, 82 insertions(+), 6 deletions(-) (In reply to Larry the Git Cow from comment #12) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=d3b53be221b0288c4eb5155ad52fa8f27bda083d > > commit d3b53be221b0288c4eb5155ad52fa8f27bda083d > Author: Magnus Granberg <zorry@gentoo.org> > AuthorDate: 2019-11-27 21:28:02 +0000 > Commit: Magnus Granberg <zorry@gentoo.org> > CommitDate: 2019-11-27 21:29:14 +0000 > > net-libs/nodejs: Fix build on PAX enable kernel (bug 694100) > > We need to disable mprotect on two bins when we compile > bug 694100. > > Closes: https://bugs.gentoo.org/694100 > Reported-by: Attila Tóth <atoth@atoth.sote.hu> > Co-developed-by: Attila Tóth <atoth@atoth.sote.hu> > Signed-off-by: Magnus Granberg <zorry@gentoo.org> > Package-Manager: Portage-2.3.76, Repoman-2.3.16 > > .../nodejs/files/nodejs-13.2.0-paxmarking.patch | 71 > ++++++++++++++++++++++ > net-libs/nodejs/metadata.xml | 1 + > net-libs/nodejs/nodejs-13.2.0.ebuild | 8 ++- > net-libs/nodejs/nodejs-99999999.ebuild | 8 ++- > 4 files changed, 82 insertions(+), 6 deletions(-) Hi Zorry, Unfortunately I have to raise this bug again. The patch takes care of marking node_mksnapshot and mkcodecache during compile. There is a third executable needs marking: mksnapshot, which had been handled by the ebuild previously. By the advent of the patch, those lines handling mksnapshot marking were removed: @@ -124,8 +128,6 @@ src_configure() { } src_compile() { - emake -C out mksnapshot - pax-mark m "out/${BUILDTYPE}/mksnapshot" emake -C out } For this reason nodejs failed to compile again. Either these lines must be reintroduced into the ebuilds or a separate or extended patch should be provided taking care of mksnapshot on top of node_mksnapshot and mkcodecache. What is your opinion about it? (In reply to Attila Tóth from comment #13) > (In reply to Larry the Git Cow from comment #12) > > The bug has been closed via the following commit(s): > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=d3b53be221b0288c4eb5155ad52fa8f27bda083d > > > > commit d3b53be221b0288c4eb5155ad52fa8f27bda083d > > Author: Magnus Granberg <zorry@gentoo.org> > > AuthorDate: 2019-11-27 21:28:02 +0000 > > Commit: Magnus Granberg <zorry@gentoo.org> > > CommitDate: 2019-11-27 21:29:14 +0000 > > > > net-libs/nodejs: Fix build on PAX enable kernel (bug 694100) > > > > We need to disable mprotect on two bins when we compile > > bug 694100. > > > > Closes: https://bugs.gentoo.org/694100 > > Reported-by: Attila Tóth <atoth@atoth.sote.hu> > > Co-developed-by: Attila Tóth <atoth@atoth.sote.hu> > > Signed-off-by: Magnus Granberg <zorry@gentoo.org> > > Package-Manager: Portage-2.3.76, Repoman-2.3.16 > > > > .../nodejs/files/nodejs-13.2.0-paxmarking.patch | 71 > > ++++++++++++++++++++++ > > net-libs/nodejs/metadata.xml | 1 + > > net-libs/nodejs/nodejs-13.2.0.ebuild | 8 ++- > > net-libs/nodejs/nodejs-99999999.ebuild | 8 ++- > > 4 files changed, 82 insertions(+), 6 deletions(-) > > Hi Zorry, > > Unfortunately I have to raise this bug again. > The patch takes care of marking node_mksnapshot and mkcodecache during > compile. There is a third executable needs marking: mksnapshot, which had > been handled by the ebuild previously. By the advent of the patch, those > lines handling mksnapshot marking were removed: > @@ -124,8 +128,6 @@ src_configure() { > } > > src_compile() { > - emake -C out mksnapshot > - pax-mark m "out/${BUILDTYPE}/mksnapshot" > emake -C out > } > > For this reason nodejs failed to compile again. Either these lines must be > reintroduced into the ebuilds or a separate or extended patch should be > provided taking care of mksnapshot on top of node_mksnapshot and mkcodecache. > > What is your opinion about it? make a patch that take care of mksnapshot. Created attachment 599250 [details, diff]
mksnapshot_paxmark.patch
Separate patch to handle mksnapshot.
(In reply to Magnus Granberg from comment #14) > (In reply to Attila Tóth from comment #13) > > (In reply to Larry the Git Cow from comment #12) > > > The bug has been closed via the following commit(s): > > > > > > > For this reason nodejs failed to compile again. Either these lines must be > > reintroduced into the ebuilds or a separate or extended patch should be > > provided taking care of mksnapshot on top of node_mksnapshot and mkcodecache. > > > > What is your opinion about it? > > make a patch that take care of mksnapshot. There it is! Created attachment 599974 [details, diff]
Updated patch to pax mark needed files
Can some one test this
The patch applies, but the build still fails. Now with mksnapshot_u instead of mksnapshot. paxctrl-ng -v out/Release/mksnapshot_u reports XATTR_PAX : not found Manually running paxctl-ng -l -m on that file produces (with -v) XATTR_PAX : -em-- Manually running paxmark.sh m on that file does not create the XATTR_PAX entry. Apparently paxmark.sh expects the variable PAX_MARKINGS to be set in make.conf, but no such variable is present and thus it silently fails while not knowing how to proceed. (the build works after adding PAX_MARKINGS definition to make.conf) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7beac2cd42801fc3ef9a1c81b9922d850e17a1c1 commit 7beac2cd42801fc3ef9a1c81b9922d850e17a1c1 Author: Magnus Granberg <zorry@gentoo.org> AuthorDate: 2020-02-17 00:33:45 +0000 Commit: Magnus Granberg <zorry@gentoo.org> CommitDate: 2020-02-17 00:37:31 +0000 net-libs/nodejs: Fix building on pax enable kernel Closes: https://bugs.gentoo.org/694100 Signed-off-by: Magnus Granberg <zorry@gentoo.org> Package-Manager: Portage-2.3.84, Repoman-2.3.16 .../nodejs/files/nodejs-13.8.0-paxmarking.patch | 111 +++++++++++++++++++++ net-libs/nodejs/nodejs-13.8.0.ebuild | 2 +- 2 files changed, 112 insertions(+), 1 deletion(-) Created attachment 776576 [details, diff]
nodejs-16.4.2-paxmarking.patch
Updated patch for nodejs-16.4.2
Created attachment 776579 [details, diff]
nodejs-18.0.0-paxmarking.patch
Updated patch for nodejs-18.0.0
In future, please file a new bug w/ the needed patches and reference this one. Let's use bug 735832 as it has all 3 patches, not just 2. Thank you for sharing them! Please file issues or pull requests upstream [1] and see if they will accept your patches. If they do, that means we don't have to keep carrying patches. Thanks, William [1] https://github.com/nodejs/node I saw a short conversation on irc that points out why we may not be able to do thi, so never mind for now. Created attachment 783803 [details, diff]
nodejs-18.3.0-paxmarking.patch
nodejs-18.3.0 removed some relevant pieces of the gyp, therefore the patch created for 18.0.0 fails to apply cleanly. This is an updated patch adapted to 18.3.0.
Created attachment 872243 [details, diff]
nodejs-20.3.0-paxmarking.patch
nodejs-20.3.0-paxmarking.patch
|