arcadia ~ # eselect profile show Current /etc/portage/make.profile symlink: default/linux/amd64/13.0/no-multilib arcadia ~ # gcc-config -l [1] x86_64-pc-linux-gnu-4.6.3 * The toolchain is not hardened, but I have pax enabled with hardened-sources. Pax.log reports: Jun 19 17:03:37 localhost kernel: PAX: execution attempt in: <anonymous mapping>, 295e22b4000-296622b4000 295e22b4000 Jun 19 17:03:37 localhost kernel: PAX: terminating task: /usr/bin/kdeinit4(plasma-desktop):2126, uid/euid: 1000/1000, PC: 00000295e22b4228, SP: 0000039d0be452b8 Jun 19 17:03:37 localhost kernel: PAX: bytes at PC: 59 49 89 4d d8 49 bb 0a 00 00 00 00 00 00 00 4d 89 5d 00 49 Jun 19 17:03:37 localhost kernel: PAX: bytes at SP-8: 0000000000000000 000002966e29a989 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00000296622c2660 00000295e1eb4048 00000296622c3960 00000296622e7a50 This does not happen with the hardened profile, and paxctl -m on kdeinit4 solves the issue.
PaX is independent of the toolchain I believe.
(In reply to Michael Palimaka (kensington) from comment #1) > PaX is independent of the toolchain I believe. It is, which is why I asked ago to file this bug. What he's saying is that a toolchain-vanilla system running under a pax hardened kernel leads to an rwx mmap while a toolchain-harcened system running under the same kernel avoids the rwx mmap. This is far outside of what I run, but I would love if I could reproduce it. ago, any change of getting an strace -f?
(In reply to Anthony Basile from comment #2) > ago, any change of getting an strace -f? It works If I start it manually. It does not work if it passes from kdeinit4
the same thing(denied mmap) happens after the wakeup: Jun 19 23:19:27 localhost kernel: PAX: execution attempt in: <anonymous mapping>, 35284dfc000-35304dfc000 35284dfc000 Jun 19 23:19:27 localhost kernel: PAX: terminating task: /usr/lib64/kde4/libexec/kscreenlocker_greet(kscreenlocker_g):4544, uid/euid: 1000/1000, PC: 0000035284dfc228, SP: 000003f68cbe4128 Jun 19 23:19:27 localhost kernel: PAX: bytes at PC: 59 49 89 4d d8 49 bb 0a 00 00 00 00 00 00 00 4d 89 5d 00 49 Jun 19 23:19:27 localhost kernel: PAX: bytes at SP-8: 0000000000000000 000003531386b989 0000000000000000 0000000000000000 0000000000000000 0000000000000000 7fffffff00000000 0000035304e0a690 00000352849fc048 0000035304e0b960 0000035304e2fa50 And if I'm stopping kdm, I can reproduce bug 472834: Jun 19 23:21:51 localhost kernel: PAX: execution attempt in: <anonymous mapping>, 0450f000-047d0000 0450f000 Jun 19 23:21:51 localhost kernel: PAX: terminating task: /usr/bin/kactivitymanagerd(QThread):2117, uid/euid: 1000/1000, PC: 00000000046777e0, SP: 000002f6072d9768 Jun 19 23:21:51 localhost kernel: PAX: bytes at PC: 20 3f 69 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 19 23:21:51 localhost kernel: PAX: bytes at SP-8: 0000000000000000 000000000040c025 00000000046f99d0 0000000000000000 00000000046f99e8 00000000046f9a10 0000000000000002 000002f60ff85aa1 0000000000000001 0000000000000001 000002f60ff5fce0
*** Bug 495092 has been marked as a duplicate of this bug. ***
Thanks for reporting. Pax marking was added on >=kde-base/kdelibs-4.12.3-r1. Please sync and test. + + 14 Mar 2014; Johannes Huber <johu@gentoo.org> +kdelibs-4.12.3-r1.ebuild: + Revision bump marks pax on /usr/bin/kdeinit4, bug #473842. +
The problem persists only if there is a non-hardened system. This fix will remove mprotect for all users (hardened included). Is this what we want?
(In reply to Agostino Sarubbo from comment #7) > The problem persists only if there is a non-hardened system. > > This fix will remove mprotect for all users (hardened included). Is this > what we want? No, we do not want this, bad idea. I do not see any of these issues running hardened-nomultilib toolchain on hardened-sources. Let's please revert this as it reduces the effectiveness of pax/grsec.
(In reply to Matt Summers from comment #8) > (In reply to Agostino Sarubbo from comment #7) > > The problem persists only if there is a non-hardened system. > > > > This fix will remove mprotect for all users (hardened included). Is this > > what we want? > > No, we do not want this, bad idea. I do not see any of these issues running > hardened-nomultilib toolchain on hardened-sources. Let's please revert this > as it reduces the effectiveness of pax/grsec. As pax-marking is forbidden we have no chance to fix it sorry.
