NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/37992: PaX flags on non-NetBSD binaries

The following reply was made to PR kern/37992; it has been noted by GNATS.

From: Elad Efrat <>
Subject: Re: kern/37992: PaX flags on non-NetBSD binaries
Date: Sun, 10 Feb 2008 14:54:49 +0200

 Andreas Wiese wrote:
 >> Number:         37992
 >> Category:       kern
 >> Synopsis:       There's no way to save PaX flags on non-native binaries
 >> Confidential:   no
 >> Severity:       non-critical
 >> Priority:       medium
 >> Responsible:    kern-bug-people
 >> State:          open
 >> Class:          sw-bug
 >> Submitter-Id:   net
 >> Arrival-Date:   Sun Feb 10 12:05:00 +0000 2008
 >> Originator:     Andreas Wiese
 >> Release:        NetBSD 4.99.49
 >> Organization:
 >         BSD-Crew Dresden, Germany
 >> Environment:
 > System: NetBSD 4.99.49 NetBSD 4.99.49
 > (SCHROEDER) #0: Tue Jan 22 18:18:53 CET 2008
 > i386
 > Architecture: i386
 > Machine: i386
 >> Description:
 > Hey, folks.
 > I played around with PaX and its several sysctl variables a while and
 > was happy to see that setting security.pax.*.global to 1 seems to work
 > for most programs.  The only native program not running was mplayer, but
 > for this I set the according flags via paxctl(8) and everything is fine.
 > Then I needed to use OpenOffice (I only have the Linux version
 > installed) and Linux glibc complained about being unable to write-enable
 > certain ELF sections.  paxctl(8) (naturally) doesn't solve the problem
 > here, so I have to disable mprotect globally to get OpenOffice work.
 > Is there any solution for this problem or had anybody an idea for this,
 > yet?  If not:  Why not save the PaX flags via the extattr(9) framework?
 > If I understood this right, its purpose is associating meta-data with
 > files, for which is no room in another way.  Why not create a
 > paxflags=0x?? key-value pair for each binary, you want to set PaX flags
 > on?  I see several advantages in this approach:
 >   1) It's transparent for different ELF formats.
 >   2) You don't touch the binary itself, therefor not messing around with
 >      checksums and veriexec(9), for example.
 >   3) You could easily transfer your binaries to another system (for
 >      whatever reason) without taking the PaX flags with you.
 >   4) We would have another use for extattr(9) to present the other guys ;)
 > Just a quick idea I wanted to share.  Could be nonsene, too =]
 > HAND & LG -- aw
 > np: nothing
 >> How-To-Repeat:
 > paxctl /path/to/linuxbinary
 >> Fix:
 > see above
 You are correct. I'm not sure what's the state of extended attributes,
 but we can use fileassoc(9). See:
 I'm pretty sure this was discussed before, but I can't seem to find the

Home | Main Index | Thread Index | Old Index