Summary: | =x11-misc/xlockmore-5.41 is killed by pax on non-hardened profile - PAX: execution attempt in: <anonymous mapping> / terminating task: /usr/bin/xlock | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | desktop-misc, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2013-06-20 15:05:15 UTC
So are you using a pax enabled kernel on a non-pax profile? That would cause problems. I don't think that is something supportable though. (In reply to Matthew Thode ( prometheanfire ) from comment #1) > So are you using a pax enabled kernel on a non-pax profile? That would > cause problems. I don't think that is something supportable though. I don't understand what you mean by pax-profile (In reply to Agostino Sarubbo from comment #2) > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > So are you using a pax enabled kernel on a non-pax profile? That would > > cause problems. I don't think that is something supportable though. > > I don't understand what you mean by pax-profile s/pax/hardened do we expect pax to work on non-hardened profiles? (In reply to Matthew Thode ( prometheanfire ) from comment #3) > (In reply to Agostino Sarubbo from comment #2) > > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > > So are you using a pax enabled kernel on a non-pax profile? That would > > > cause problems. I don't think that is something supportable though. > > > > I don't understand what you mean by pax-profile > > s/pax/hardened > > do we expect pax to work on non-hardened profiles? Why not? For what you are saying, pax should be able to work only on gentoo.. (In reply to Matthew Thode ( prometheanfire ) from comment #3) > (In reply to Agostino Sarubbo from comment #2) > > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > > So are you using a pax enabled kernel on a non-pax profile? That would > > > cause problems. I don't think that is something supportable though. > > > > I don't understand what you mean by pax-profile > > s/pax/hardened > > do we expect pax to work on non-hardened profiles? Why would xlock, compiled with a vanilla toolchain die with exec attempts in anon mappings whereas xlock compiled with a hardened toolchain be fine? its not clear what's at the bottom of this. i have not tried to reproduce. (In reply to Anthony Basile from comment #5) > (In reply to Matthew Thode ( prometheanfire ) from comment #3) > > (In reply to Agostino Sarubbo from comment #2) > > > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > > > So are you using a pax enabled kernel on a non-pax profile? That would > > > > cause problems. I don't think that is something supportable though. > > > > > > I don't understand what you mean by pax-profile > > > > s/pax/hardened > > > > do we expect pax to work on non-hardened profiles? > > Why would xlock, compiled with a vanilla toolchain die with exec attempts in > anon mappings whereas xlock compiled with a hardened toolchain be fine? its > not clear what's at the bottom of this. i have not tried to reproduce. Ago, can you paste the ldd output of your xlock? Mainly to see if it is linked against one of the usual offenders. (In reply to Francisco Blas Izquierdo Riera from comment #6) > (In reply to Anthony Basile from comment #5) > > (In reply to Matthew Thode ( prometheanfire ) from comment #3) > > > (In reply to Agostino Sarubbo from comment #2) > > > > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > > > > So are you using a pax enabled kernel on a non-pax profile? That would > > > > > cause problems. I don't think that is something supportable though. > > > > > > > > I don't understand what you mean by pax-profile > > > > > > s/pax/hardened > > > > > > do we expect pax to work on non-hardened profiles? > > > > Why would xlock, compiled with a vanilla toolchain die with exec attempts in > > anon mappings whereas xlock compiled with a hardened toolchain be fine? its > > not clear what's at the bottom of this. i have not tried to reproduce. > > Ago, can you paste the ldd output of your xlock? Mainly to see if it is > linked against one of the usual offenders. Its a long list below, but if it linked against one of the offenders, it would equally fail if built under a hardened profile unless USE=jit or one of those flags were on, and I asked ago to turn off those, as well as enable pax_kernel. linux-vdso.so.1 (0x00007fff51342000) libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x00007f6fea021000) libMagickCore.so.5 => /usr/lib64/libMagickCore.so.5 (0x00007f6fe9b5e000) libftgl.so.2 => /usr/lib64/libftgl.so.2 (0x00007f6fe992b000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f6fe96a0000) libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f6fe9413000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f6fe91ff000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f6fe8ffc000) libaudio.so.2 => /usr/lib64/libaudio.so.2 (0x00007f6fe8ddf000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f6fe8ba8000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f6fe8856000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libstdc++.so.6 (0x00007f6fe8538000) libm.so.6 => /lib64/libm.so.6 (0x00007f6fe8242000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libgcc_s.so.1 (0x00007f6fe802b000) libc.so.6 => /lib64/libc.so.6 (0x00007f6fe7c82000) libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x00007f6fe78ec000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f6fe76b0000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f6fe7403000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f6fe71f3000) libz.so.1 => /lib64/libz.so.1 (0x00007f6fe6fdc000) libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libgomp.so.1 (0x00007f6fe6dcb000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6fe6bae000) libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f6fe69a2000) libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007f6fe674d000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f6fe654a000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f6fe6343000) libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007f6fe6141000) libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007f6fe5f21000) libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007f6fe5d1b000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f6fe5af3000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f6fe58ed000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f6fe56df000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f6fe54db000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x00007f6fe526b000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f6fe5067000) /lib64/ld-linux-x86-64.so.2 (0x00007f6fea234000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f6fe4e39000) librt.so.1 => /lib64/librt.so.1 (0x00007f6fe4c30000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f6fe4a29000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f6fe4820000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f6fe4603000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f6fe43fe000) (In reply to Francisco Blas Izquierdo Riera from comment #6) > Ago, can you paste the ldd output of your xlock? Mainly to see if it is > linked against one of the usual offenders. linux-gate.so.1 (0xa09fd000) libXpm.so.4 => /usr/lib/libXpm.so.4 (0xa09df000) libGL.so.1 => /usr/lib/libGL.so.1 (0xa0981000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xa08f9000) libXext.so.6 => /usr/lib/libXext.so.6 (0xa08e6000) libpam.so.0 => /lib/libpam.so.0 (0xa08d7000) libX11.so.6 => /usr/lib/libX11.so.6 (0xa0793000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/libstdc++.so.6 (0xa06ab000) libm.so.6 => /lib/libm.so.6 (0xa0680000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/libgcc_s.so.1 (0xa0662000) libc.so.6 => /lib/libc.so.6 (0xa04be000) libglapi.so.0 => /usr/lib/libglapi.so.0 (0xa04a8000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xa04a4000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xa049e000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xa049b000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xa0481000) libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0xa047b000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xa0458000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xa0451000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xa0444000) libpthread.so.0 => /lib/libpthread.so.0 (0xa0428000) libdl.so.2 => /lib/libdl.so.2 (0xa0423000) /lib/ld-linux.so.2 (0xa09fe000) libXau.so.6 => /usr/lib/libXau.so.6 (0xa041f000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xa0418000) librt.so.1 => /lib/librt.so.1 (0xa040e000) I dare say this is obsolete by now. Let us know if it's not. I can't personally test with PaX. |