Mailing List Archive: nvidia.ko with Grsecurity & PaX kernel

nvidia.ko with Grsecurity & PaX kernel

Sep 11, 2013, 9:57 AM

Post #1 of 13 (8907 views)

Hello!

I have a Dell Inspiron N5110 laptop with Optimus. I used Xorg with the
Intel driver only until now, but I was thinking to start using the
nVidia card as well, because the HDMI output is connected directly to
the nVidia GPU.

My kernel:
Linux 3.10.1-hardened-r1 #4 SMP PREEMPT Sat Sep 7 17:26:02 EEST 2013
x86_64 Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz GenuineIntel GNU/Linux

Please find at the and of the mail the relevant kernel config part.

I emerged =nvidia-drivers-325.15 successfully, but I cannot load the
nvidia module:

# modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': Exec format error

The kernel log does not contain any information about this. I tried
also with the stable 319.49 as well, but the error is the same.

Do you know whether this is a (known) bug in the driver/ebuild or is a
problematic GRSEC/PAX option in my kernel config?

Regards,
Balint

Relevant log:
CONFIG_PAX_KERNEXEC_PLUGIN=y
CONFIG_PAX_PER_CPU_PGD=y
CONFIG_PAX_USERCOPY_SLABS=y
CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CONFIG_CUSTOM=y
CONFIG_GRKERNSEC_PROC_GID=10
CONFIG_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_NO_ACL_FLAGS=y
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_MPROTECT=y
CONFIG_PAX_KERNEXEC=y
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR=y
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="or"
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_MEMORY_STRUCTLEAK=y
CONFIG_PAX_MEMORY_UDEREF=y
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_CONSTIFY_PLUGIN=y
CONFIG_PAX_USERCOPY=y
CONFIG_PAX_SIZE_OVERFLOW=y
CONFIG_PAX_LATENT_ENTROPY=y
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_RAND_THREADSTACK=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_MODHARDEN=y
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_DEVICE_SIDECHANNEL=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_PTRACE=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_RWXMAP_LOG=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_HARDEN_PTRACE=y
CONFIG_GRKERNSEC_PTRACE_READEXEC=y
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_BLACKHOLE=y
CONFIG_GRKERNSEC_NO_SIMULT_CONNECT=y
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=6

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

amade at asmblr

Sep 11, 2013, 10:55 AM

Post #2 of 13 (8786 views)

Permalink

On Wed, 11 Sep 2013 19:57:03 +0300
Balint Szente <balint@szentedwg.ro> wrote:

> Hello!
>
>
> I have a Dell Inspiron N5110 laptop with Optimus. I used Xorg with the
> Intel driver only until now, but I was thinking to start using the
> nVidia card as well, because the HDMI output is connected directly to
> the nVidia GPU.
>
> My kernel:
> Linux 3.10.1-hardened-r1 #4 SMP PREEMPT Sat Sep 7 17:26:02 EEST 2013
> x86_64 Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz GenuineIntel
> GNU/Linux
>
> Please find at the and of the mail the relevant kernel config part.
>
> I emerged =nvidia-drivers-325.15 successfully, but I cannot load the
> nvidia module:
>
> # modprobe nvidia
> modprobe: ERROR: could not insert 'nvidia': Exec format error
>
> The kernel log does not contain any information about this. I tried
> also with the stable 319.49 as well, but the error is the same.
>
> Do you know whether this is a (known) bug in the driver/ebuild or is a
> problematic GRSEC/PAX option in my kernel config?
>
> Regards,
> Balint
>
> Relevant log:
> CONFIG_PAX_KERNEXEC_PLUGIN=y
> CONFIG_PAX_PER_CPU_PGD=y
> CONFIG_PAX_USERCOPY_SLABS=y
> CONFIG_GRKERNSEC=y
> CONFIG_GRKERNSEC_CONFIG_CUSTOM=y
> CONFIG_GRKERNSEC_PROC_GID=10
> CONFIG_PAX=y
> CONFIG_PAX_PT_PAX_FLAGS=y
> CONFIG_PAX_NO_ACL_FLAGS=y
> CONFIG_PAX_NOEXEC=y
> CONFIG_PAX_PAGEEXEC=y
> CONFIG_PAX_EMUTRAMP=y
> CONFIG_PAX_MPROTECT=y
> CONFIG_PAX_KERNEXEC=y
> CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR=y
> CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="or"
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR:
This method is incompatible with binary only modules but
has a lower runtime overhead.

Try using bts

> CONFIG_PAX_ASLR=y
> CONFIG_PAX_RANDKSTACK=y
> CONFIG_PAX_RANDUSTACK=y
> CONFIG_PAX_RANDMMAP=y
> CONFIG_PAX_MEMORY_STACKLEAK=y
> CONFIG_PAX_MEMORY_STRUCTLEAK=y
> CONFIG_PAX_MEMORY_UDEREF=y
> CONFIG_PAX_REFCOUNT=y
> CONFIG_PAX_CONSTIFY_PLUGIN=y
> CONFIG_PAX_USERCOPY=y
> CONFIG_PAX_SIZE_OVERFLOW=y
> CONFIG_PAX_LATENT_ENTROPY=y
> CONFIG_GRKERNSEC_KMEM=y
> CONFIG_GRKERNSEC_RAND_THREADSTACK=y
> CONFIG_GRKERNSEC_PROC_MEMMAP=y
> CONFIG_GRKERNSEC_BRUTE=y
> CONFIG_GRKERNSEC_MODHARDEN=y
> CONFIG_GRKERNSEC_HIDESYM=y
> CONFIG_GRKERNSEC_ACL_HIDEKERN=y
> CONFIG_GRKERNSEC_ACL_MAXTRIES=3
> CONFIG_GRKERNSEC_ACL_TIMEOUT=30
> CONFIG_GRKERNSEC_PROC=y
> CONFIG_GRKERNSEC_PROC_USERGROUP=y
> CONFIG_GRKERNSEC_PROC_ADD=y
> CONFIG_GRKERNSEC_LINK=y
> CONFIG_GRKERNSEC_FIFO=y
> CONFIG_GRKERNSEC_DEVICE_SIDECHANNEL=y
> CONFIG_GRKERNSEC_CHROOT=y
> CONFIG_GRKERNSEC_CHROOT_MOUNT=y
> CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
> CONFIG_GRKERNSEC_CHROOT_PIVOT=y
> CONFIG_GRKERNSEC_CHROOT_CHDIR=y
> CONFIG_GRKERNSEC_CHROOT_CHMOD=y
> CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
> CONFIG_GRKERNSEC_CHROOT_MKNOD=y
> CONFIG_GRKERNSEC_CHROOT_SHMAT=y
> CONFIG_GRKERNSEC_CHROOT_UNIX=y
> CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
> CONFIG_GRKERNSEC_CHROOT_NICE=y
> CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
> CONFIG_GRKERNSEC_CHROOT_CAPS=y
> CONFIG_GRKERNSEC_RESLOG=y
> CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
> CONFIG_GRKERNSEC_AUDIT_PTRACE=y
> CONFIG_GRKERNSEC_AUDIT_MOUNT=y
> CONFIG_GRKERNSEC_SIGNAL=y
> CONFIG_GRKERNSEC_FORKFAIL=y
> CONFIG_GRKERNSEC_TIME=y
> CONFIG_GRKERNSEC_PROC_IPADDR=y
> CONFIG_GRKERNSEC_RWXMAP_LOG=y
> CONFIG_GRKERNSEC_DMESG=y
> CONFIG_GRKERNSEC_HARDEN_PTRACE=y
> CONFIG_GRKERNSEC_PTRACE_READEXEC=y
> CONFIG_GRKERNSEC_RANDNET=y
> CONFIG_GRKERNSEC_BLACKHOLE=y
> CONFIG_GRKERNSEC_NO_SIMULT_CONNECT=y
> CONFIG_GRKERNSEC_FLOODTIME=10
> CONFIG_GRKERNSEC_FLOODBURST=6
>

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

balint at szentedwg

Sep 11, 2013, 1:44 PM

Post #3 of 13 (8789 views)

Permalink

On Wed, 11 Sep 2013 19:55:13 +0200
Amadeusz SÅ‚awiÅ„ski <amade@asmblr.net> wrote:

> [...]
> > CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR=y
> > CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="or"
> CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR:
> This method is incompatible with binary only modules but
> has a lower runtime overhead.
>
> Try using bts

Yes, of course! Stupid me. This was it... thank you very much.

Now there is another issue:
kernel: grsec: denied RWX mmap of /usr/lib64/opengl/nvidia/lib/libGL.so.325.15
on pretty much everything, but it is a known issue:
<https://bugs.gentoo.org/show_bug.cgi?id=433121>

So I disabled CONFIG_PAX_MPROTECT for the moment.

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

h.v.bruinehsen at fu-berlin

Sep 11, 2013, 1:57 PM

Post #4 of 13 (8815 views)

Permalink

On Wed, Sep 11, 2013 at 11:44:07PM +0300, Balint Szente wrote:
> On Wed, 11 Sep 2013 19:55:13 +0200
> Amadeusz SÅ‚awiÅ„ski <amade@asmblr.net> wrote:
>
> > [...]
> > > CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR=y
> > > CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="or"
> > CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR:
> > This method is incompatible with binary only modules but
> > has a lower runtime overhead.
> >
> > Try using bts
>
> Yes, of course! Stupid me. This was it... thank you very much.
>
> Now there is another issue:
> kernel: grsec: denied RWX mmap of /usr/lib64/opengl/nvidia/lib/libGL.so.325.15
> on pretty much everything, but it is a known issue:
> <https://bugs.gentoo.org/show_bug.cgi?id=433121>
>
> So I disabled CONFIG_PAX_MPROTECT for the moment.

I'd rather paxctl(-ng) -m the offenders and keep CONFIG_PAX_MPROTECT=y- that way you'd have mprotect for at
least everything else. You can also use blueness revdep-pax to make the process
easier...

WKR
Hinnerk

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

powerman at powerman

Sep 11, 2013, 2:24 PM

Post #5 of 13 (8793 views)

Permalink

Hi!

On Wed, Sep 11, 2013 at 11:44:07PM +0300, Balint Szente wrote:
> So I disabled CONFIG_PAX_MPROTECT for the moment.

It's much better to `paxctl-ng -m /usr/bin/Xorg` instead. And probably few
other applications (mplayer, glxgears, etc.).

Also, you can install latest stable nvidia-drivers by simple removing this
line from ebuild (bug already reported):

epatch "${FILESDIR}"/nvidia-drivers-pax-const.patch

Main issue with nvidia-drivers on hardened is what sometimes some race
condition happens and system just freezes. This may happens when starting
mplayer with hardware acceleration:
mplayer -vf-clr -vo vdpau -vc ffh264vdpau,ffmpeg12vdpau, â€¦
or just in the middle of viewing video using flash in browser.

Not sure about flash, but when this happens with mplayer I've tried to
analyse what's going on: system is working, but incredible slow, it took
about 10 minutes to switch to another virtual desktop, run top, found
mplayer process using 100% CPU, try to kill it (don't remember is it was
successful or not), but it won't fix anything - system still was too slow.
In all cases I've to press RESET because trying to do normal shutdown
procedure may took hours.

--
WBR, Alex.

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

balint at szentedwg

Sep 14, 2013, 5:33 AM

Post #6 of 13 (8779 views)

Permalink

Hello!

Thank you Alex and Hinnerk for your answers.

I understand and fully agree that CONFIG_PAX_MPROTECT is very important
for security. However, I had to "-m" mark *a lot* of applications:

Xorg, i3, i3bar, i3-nagbar and even "simple" GTK applications like
claws-mail that has nothing with GLX (or maybe GTK has).

I'm aware of the latest-stable ebuild issue with the pax-const.patch,
but do you think it would make a difference from MPROTECT marking
point of view? Is 319.49 behaving "more nicely" then 325.15?

Thank you,
Balint

On Thu, 12 Sep 2013 00:24:59 +0300
Alex Efros <powerman@powerman.name> wrote:

> Hi!
>
> On Wed, Sep 11, 2013 at 11:44:07PM +0300, Balint Szente wrote:
> > So I disabled CONFIG_PAX_MPROTECT for the moment.
>
> It's much better to `paxctl-ng -m /usr/bin/Xorg` instead. And
> probably few other applications (mplayer, glxgears, etc.).
>
>
> Also, you can install latest stable nvidia-drivers by simple removing
> this line from ebuild (bug already reported):
>
> epatch "${FILESDIR}"/nvidia-drivers-pax-const.patch
>
>
> Main issue with nvidia-drivers on hardened is what sometimes some race
> condition happens and system just freezes. This may happens when
> starting mplayer with hardware acceleration:
> mplayer -vf-clr -vo vdpau -vc ffh264vdpau,ffmpeg12vdpau, â€¦
> or just in the middle of viewing video using flash in browser.
>
> Not sure about flash, but when this happens with mplayer I've tried to
> analyse what's going on: system is working, but incredible slow, it
> took about 10 minutes to switch to another virtual desktop, run top,
> found mplayer process using 100% CPU, try to kill it (don't remember
> is it was successful or not), but it won't fix anything - system
> still was too slow. In all cases I've to press RESET because trying
> to do normal shutdown procedure may took hours.
>

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

balint at szentedwg

Sep 19, 2013, 9:49 AM

Post #7 of 13 (8749 views)

Permalink

Hello!

Just a short follow-up: I installed 319.49 as well, but the situation
is the same. A lot of applications give this error:

error while loading shared libraries: libGL.so.1: failed to map
segment from shared object: Operation not permitted

So no difference between 325.15 and 319.49 from this point of view.

I kept MPROTECT after all as you guys recommended, and I decided to use
revdep-pax. Unfortunately I encountered the following issue:

# revdep-pax -m -l /usr/lib/libGL.so
libGL.so.1 /usr/lib64/opengl/nvidia/lib/libGL.so.319.49 :X86_64 (-em--)

/usr/bin/cairo-sphinx ( -e--- )
/usr/bin/glxgears ( -e--- )
/usr/lib64/libcairo.so.2.11200.14 ( -e--- )
/usr/bin/vwebp ( -e--- )
/usr/lib64/libwebkitgtk-1.0.so.0.13.4 ( -e--- )
/usr/bin/glxinfo ( -e--- )
/usr/bin/xdriinfo ( -e--- )
/usr/lib64/libglut.so.3.9.0 ( -e--- )
/usr/lib64/libva-glx.so.1.3300.0 ( -e--- )
/usr/lib64/libGLU.so.1.3.1 ( -e--- )
/usr/lib64/va/drivers/vdpau_drv_video.so ( -e--- )

Will mark elf with -em--

Set flags for /usr/bin/cairo-sphinx (y/n): y

/usr/bin/cairo-sphinx ( ----- )

Set flags for /usr/bin/glxgears (y/n): y

/usr/bin/glxgears ( ----- )

The script actually *erased* the pax markings, instead of marking with
-em--:

# paxctl-ng -v /usr/bin/glxgears
/usr/bin/glxgears:
PT_PAX : -----
XATTR_PAX : -----

Do you have any ideas about this issue?

Notes: I use PT markings in kernel, and I have PAX_MARKINGS="PT" in
make.conf.

Thanks,
Balint

On Sat, 14 Sep 2013 15:33:56 +0300
Balint Szente <balint@szentedwg.ro> wrote:

> [...]
> I understand and fully agree that CONFIG_PAX_MPROTECT is very
> important for security. However, I had to "-m" mark *a lot* of
> applications:
>
> Xorg, i3, i3bar, i3-nagbar and even "simple" GTK applications like
> claws-mail that has nothing with GLX (or maybe GTK has).
>
> I'm aware of the latest-stable ebuild issue with the pax-const.patch,
> but do you think it would make a difference from MPROTECT marking
> point of view? Is 319.49 behaving "more nicely" then 325.15?

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

basile at opensource

Sep 20, 2013, 3:31 AM

Post #8 of 13 (8740 views)

Permalink

On 09/19/2013 12:49 PM, Balint Szente wrote:
> Hello!
>
>
> Just a short follow-up: I installed 319.49 as well, but the situation
> is the same. A lot of applications give this error:
>
> error while loading shared libraries: libGL.so.1: failed to map
> segment from shared object: Operation not permitted
>
> So no difference between 325.15 and 319.49 from this point of view.
>
> I kept MPROTECT after all as you guys recommended, and I decided to use
> revdep-pax. Unfortunately I encountered the following issue:
>
> # revdep-pax -m -l /usr/lib/libGL.so
> libGL.so.1 /usr/lib64/opengl/nvidia/lib/libGL.so.319.49 :X86_64 (-em--)
>
> /usr/bin/cairo-sphinx ( -e--- )
> /usr/bin/glxgears ( -e--- )
> /usr/lib64/libcairo.so.2.11200.14 ( -e--- )
> /usr/bin/vwebp ( -e--- )
> /usr/lib64/libwebkitgtk-1.0.so.0.13.4 ( -e--- )
> /usr/bin/glxinfo ( -e--- )
> /usr/bin/xdriinfo ( -e--- )
> /usr/lib64/libglut.so.3.9.0 ( -e--- )
> /usr/lib64/libva-glx.so.1.3300.0 ( -e--- )
> /usr/lib64/libGLU.so.1.3.1 ( -e--- )
> /usr/lib64/va/drivers/vdpau_drv_video.so ( -e--- )
>
> Will mark elf with -em--
>
> Set flags for /usr/bin/cairo-sphinx (y/n): y
>
> /usr/bin/cairo-sphinx ( ----- )
>
> Set flags for /usr/bin/glxgears (y/n): y
>
> /usr/bin/glxgears ( ----- )
>
> The script actually *erased* the pax markings, instead of marking with
> -em--:
>
> # paxctl-ng -v /usr/bin/glxgears
> /usr/bin/glxgears:
> PT_PAX : -----
> XATTR_PAX : -----
>
> Do you have any ideas about this issue?
>
> Notes: I use PT markings in kernel, and I have PAX_MARKINGS="PT" in
> make.conf.
>
> Thanks,
> Balint
>
> On Sat, 14 Sep 2013 15:33:56 +0300
> Balint Szente <balint@szentedwg.ro> wrote:

I wrote that script but I've never seen this before. I suspect there's
something wrong with the pypax python module. Can you test using
pypaxctl to set some pax flags on a non-critical elf binary and see if
it works.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

balint at szentedwg

Sep 21, 2013, 9:55 AM

Post #9 of 13 (8744 views)

Permalink

Hello Anthony!

pypaxctl itself works, but I found the way to reproduce the issue:

1. Set the PT flags for the nvidia GL library:

# paxctl -c /usr/lib/opengl/nvidia/lib/libGL.so.325.15
# paxctl-ng -em /usr/lib/opengl/nvidia/lib/libGL.so.325.15
# paxctl-ng -v /usr/lib/opengl/nvidia/lib/libGL.so.325.15
/usr/lib/opengl/nvidia/lib/libGL.so.325.15:
PT_PAX : -em--
XATTR_PAX : -em--

2. Delete the XT_ATTR PAX flags (because I don't use XT):

# pypaxctl -d /usr/lib/opengl/nvidia/lib/libGL.so.325.15
# paxctl-ng -v /usr/lib/opengl/nvidia/lib/libGL.so.325.15
/usr/lib/opengl/nvidia/lib/libGL.so.325.15:
PT_PAX : -em--
XATTR_PAX : not found

3. Run revdep-pax:

# paxctl-ng -v /usr/bin/glxgears
/usr/bin/glxgears:
PT_PAX : -e---
XATTR_PAX : not found
# revdep-pax -m -l /usr/lib/libGL.so
libGL.so.1 /usr/lib64/opengl/nvidia/lib/libGL.so.325.15 :X86_64 (-em--)

/usr/bin/glxgears ( -e--- )
[...]

Will mark elf with -em--

Set flags for /usr/bin/glxgears (y/n): y

/usr/bin/glxgears ( ----- )
# paxctl-ng -v /usr/bin/glxgears
/usr/bin/glxgears:
PT_PAX : -----
XATTR_PAX : -----

Step 2. is the trigger for the problem. If I don't delete the XT_ATTR
PAX flags from the GL library, then the revdep-pax script works well.

So as a conclusion, I think the issue appears when the library has only
PT marks.

Regards,
Balint

On Fri, 20 Sep 2013 06:31:03 -0400
"Anthony G. Basile" <basile@opensource.dyc.edu> wrote:
>
> I wrote that script but I've never seen this before. I suspect
> there's something wrong with the pypax python module. Can you test
> using pypaxctl to set some pax flags on a non-critical elf binary and
> see if it works.
>

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

h.v.bruinehsen at fu-berlin

Sep 21, 2013, 11:01 AM

Post #10 of 13 (8734 views)

Permalink

On Sat, Sep 21, 2013 at 07:55:40PM +0300, Balint Szente wrote:
> Hello Anthony!
>
>
> pypaxctl itself works, but I found the way to reproduce the issue:
>
> 1. Set the PT flags for the nvidia GL library:
>
> # paxctl -c /usr/lib/opengl/nvidia/lib/libGL.so.325.15
> # paxctl-ng -em /usr/lib/opengl/nvidia/lib/libGL.so.325.15
> # paxctl-ng -v /usr/lib/opengl/nvidia/lib/libGL.so.325.15
> /usr/lib/opengl/nvidia/lib/libGL.so.325.15:
> PT_PAX : -em--
> XATTR_PAX : -em--
>
> 2. Delete the XT_ATTR PAX flags (because I don't use XT):
>
> # pypaxctl -d /usr/lib/opengl/nvidia/lib/libGL.so.325.15
> # paxctl-ng -v /usr/lib/opengl/nvidia/lib/libGL.so.325.15
> /usr/lib/opengl/nvidia/lib/libGL.so.325.15:
> PT_PAX : -em--
> XATTR_PAX : not found
>
> 3. Run revdep-pax:
>
> # paxctl-ng -v /usr/bin/glxgears
> /usr/bin/glxgears:
> PT_PAX : -e---
> XATTR_PAX : not found
> # revdep-pax -m -l /usr/lib/libGL.so
> libGL.so.1 /usr/lib64/opengl/nvidia/lib/libGL.so.325.15 :X86_64 (-em--)
>
> /usr/bin/glxgears ( -e--- )
> [...]
>
> Will mark elf with -em--
>
> Set flags for /usr/bin/glxgears (y/n): y
>
> /usr/bin/glxgears ( ----- )
> # paxctl-ng -v /usr/bin/glxgears
> /usr/bin/glxgears:
> PT_PAX : -----
> XATTR_PAX : -----
>
> Step 2. is the trigger for the problem. If I don't delete the XT_ATTR
> PAX flags from the GL library, then the revdep-pax script works well.
>
> So as a conclusion, I think the issue appears when the library has only
> PT marks.
>
Why would you remove XT-pax flags anyways? It's just xattr (shouldn't cause
much overhead) and since PT-pax is going to be deprecated (iirc soon), you have
a backup with the XT-pax flags (so you don't have breakage when the switch
occurs).

WKR
Hinnerk

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

balint at szentedwg

Sep 21, 2013, 1:34 PM

Post #11 of 13 (8734 views)

Permalink

On Sat, 21 Sep 2013 20:01:57 +0200
Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> wrote:

> > [...]
> >
> Why would you remove XT-pax flags anyways?

Because I don't use XT flags (yet) and I like to keep things "clean"
and consistent. I have PAX_MARKINGS="PT" in my make.conf, so every ELF
is PT marked only. This was the reason that I removed the XT marks from
the nVidia shared object. On the other hand it excludes the possibility
of inconsistent XT and PT markings.

> It's just xattr (shouldn't
> cause much overhead) and since PT-pax is going to be deprecated (iirc
> soon), you have a backup with the XT-pax flags (so you don't have
> breakage when the switch occurs).

I know and agree that XT markings are superior, especially for a closed
source binary file where altering the ELF header is not necessarily
safe. But I was thinking to wait until XT-pax markings will get stable
(bug #465000).

Regards,
Balint

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

atoth at atoth

Sep 22, 2013, 7:19 AM

Post #12 of 13 (8753 views)

Permalink

2013.Szeptember 21.(Szo) 20:01 idÅ‘pontban Hinnerk van Bruinehsen ezt Ãrta:
> On Sat, Sep 21, 2013 at 07:55:40PM +0300, Balint Szente wrote:
>>
>> pypaxctl itself works, but I found the way to reproduce the issue:
>>
>> Step 2. is the trigger for the problem. If I don't delete the XT_ATTR
>> PAX flags from the GL library, then the revdep-pax script works well.
>>
>> So as a conclusion, I think the issue appears when the library has only
>> PT marks.
>>
> Why would you remove XT-pax flags anyways? It's just xattr (shouldn't
> cause
> much overhead) and since PT-pax is going to be deprecated (iirc soon), you
> have
> a backup with the XT-pax flags (so you don't have breakage when the
> switch
> occurs).
>
>
> WKR
> Hinnerk
>

Dear Hinnerk,

I have both PT and XT support compiled into my kernel and I have both PT
and XT PAX flags defined in my make.conf. Using the latest hardened
overlay, it installs binaries with PT marking only. So the installed
binary is just like what Balint produced by erasing the XT attributes.
Now if I run revdep-pax, the situation remains the same.
Actually I've already put together some commands to look for XT-less
binaries and paxctl-ng them properly.

The issue is probably related to the fact, that previously an install
wrapper in portage turned out to slow down things significantly, so it was
removed. GNU install won't preserve XT pax markings. It was told on this
mailing list, that an updated solution will come, which makes install
preserve XT attributes for PAX.

We can expect more to come regarding XT support in the future and help
testing it.

Regards:
Dw.
--
dr TÃ³th Attila, RadiolÃ³gus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

Re: nvidia.ko with Grsecurity & PaX kernel [ In reply to ]

balint at szentedwg

Sep 26, 2013, 10:42 PM

Post #13 of 13 (8707 views)

Permalink

Hello Anthony!

On Sat, 21 Sep 2013 19:55:40 +0300
Balint Szente <balint@szentedwg.ro> wrote:

> [...]
>
> Step 2. is the trigger for the problem. If I don't delete the XT_ATTR
> PAX flags from the GL library, then the revdep-pax script works well.
>
> So as a conclusion, I think the issue appears when the library has
> only PT marks.

Maybe it is more appropriate to report this Bugzilla. Would it help you
if I make a bug report on Gentoo Bugzilla?

Regards,
Balint

Mailing List Archive

Attached Files:

Attached Files: