Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

This bug is just an update bug for the /etc/conf.d/chpax configuration.  I
searched for "chpax" and didn't find a similar bug.

Reproducible: Always
Steps to Reproduce:
1. Set up a kernel with pax
2. Run a program
3. Watch it be killed.

Actual Results:  
Program got killed

Expected Results:  
Should have ran.

Created an attachment (id=25115) [details]
chpax from Bluefox -- 20030206

I can't guarentee the usefulness of everything, but in my experience, PE_wine,
PE_gnome, PE_xfce, PEMISC, and PE_openoffice are needed.  I haven't tested to
see if PE_blackdown_java and friends do their job yet, but I got the tip about
mprotect from someone else.

Lets start with whats a PE_* ?

Created an attachment (id=25829) [details]
new chpax init.d script

This is a patch to the /etc/init.d/chpax script that fixes it for conf.d/chpax
configurations that need shell	evaluation, especilly those like the one I'm
about to upload.  Settings including /path/to/{multiple,binaries} were
evaluated as pointing at a file of that name as opposed to two files, causing
the configuration to not work.	This makes these allowed.  It requires bash to
not be broken, so it doesn't create any new dependencies.

Created an attachment (id=25831) [details]
chpax conf.d from Bluefox -- 20040218

Makes wine actually work, has a more condensed java line, yadda yadda.	It's a
new conf.d file, not a patch.

solar:  the header of my copy of conf.d/chpax configurations (I've attatched
two so far) explain what each of the prefixes do, and link them to a
corrosponding chpax flag.

# chpax prefix  description
# p     PE      do not enforce paging based non-executable pages
# E     ET      emulate trampolines
# r     RE      do not randomize mmap() base [ELF only]
# m     ME      do not restrict mprotect()
# s     SE      do not enforce segmentation based non-executable pages
# x     XE      do not randomize ET_EXEC base [ELF only]

PE would be "Pageexec Exempt," ET would be "Emulate Trampolines," ME would be
"Mprotect() restriction Exempt," and so on.

Created an attachment (id=26077) [details]
chpax init.d patch to whatever was in the portage tree at the time.

remember to appropriately set your $CHPAX variable in /etc/conf.d/chpax or
it'll default to /sbin/chpax

I have my $CHPAX set to /sbin/paxctl, and it's this way in the new config patch
as well.

Created an attachment (id=26078) [details]
conf.d patch 20040221

chpax conf.d patch for 20040221 to whatever was in the portage tree at the
time, counterparts the above init.d

Created an attachment (id=26080) [details]
Re butchered conf file.

${PE_gnome} can come out.

See anything else? 

I just want to try to keep the file clean/simple and easy to read as we can.

I guess PE_{gnome,xfce4,bzflag} can be merged with PEMISC.  As for being
dropped, I haven't tested the gnome-sound-recorder since I put that in my file;
it got "Killed" (PaX) without it, and "Segmentation Fault" (bad programming)
with it, so I really had no reason to check since then.

wine and java are both shotguns; I don't honestly know which of any of those is
causing a problem, but it's definitely multiple.  It MAY be all of them, but
I'd have to give it a good going-over to actually determine what we can take
out of there.  I had wine working when I set up the extra like four that
weren't there before; but now I have neither wine nor java working (even with
chpax/paxctl -pEmrxs), so I can't start ripping out ones that we don't need and
testing.  My system's a bit hurt, I just remerged world to get a few things
back up and running.  :)

hrmm this is another reason for pax logging of permissions :)

{gnome,xfce4,bzflag}
I pulled those out cuz they were only one file.

I'm wanting to get in the habit of fixing these problematic programs at 
the source level vs permitting them via any elf markings. We have to ask
ourselves why do these programs need any marking on them in the first
place.. The whole idea behind PaX is the prevention of W^X and giving
these bits is self defeating.. I guess what I'm getting at is you and 
swtaylor are best users/testers/bug reporters of pax/pie/etc and we 
could really use your help at trying to take a closer look at these bugs
that exist in the first place.

Anyway I'll add the patches to portage when I'm sober sometime tmw afternoon.
I'll look for if any bugs show up :P

I'm not into just jumping on everyone's code and fixing it, sorry.  I stay to
chunks of code I know.  Right now, I understand the Linux kernel to a small
degree, and code mostly in there.  That doesn't mean I can suddenly jump into
the 7zip project and port lzma to a library in Linux, or jump into Gimp and add
vector based layers, much less jump into any random broken program and fix its
W|X requirement.  It would take me probably weeks if not months to grok the
code, and there's no guarentee I can really fix it.

You could always try to get the developers to cooperate with you.  This is
going to be easier once pip is satisfied with PaX' development and decides to
push PaX towards the kernel devs and try to get them to pull it into
mainstream; developers have to code for what you cram in their face, but
they'll ignore things on the shelf for as long as possible.  Either way, we
have to get everyone interested in it or else these bugs simply won't get
fixed, or will be piled on top of some unlucky workhorse.

Created an attachment (id=26857) [details]
pax-conf.d.20040304.diff

This is a conf.d patch to /usr/portage/sys-apps/chpax/files/pax-conf.d as of
20040304 to my current.  An emerge sync was made a few hours prior on the same
day.

Created an attachment (id=26858) [details]
pax-init.d.20040304.diff

This was made along with the above conf.d patch

Created an attachment (id=26860) [details]
pax-init.d.20040304.1.diff

Sorry about that, I forgot about some of PaX' brainpower, particularly, it
looks for things that make no sense.

In the event that -p and -s are set, the protection that kills trampolines and
thus creates the need for -E makes no sense.  Also, the protection provided by
restricted mprotect() (-M) makes no sense either.  PaX doesn't like it when
flags that don't make sense exist.

In short, PE/SE settings need to be applied after -m and -e, as -pem and -sem
instead of -p and -s.  This is what I missed about 4 minutes ago.

This patch goes on the same file that the other one does, and is used in place
of pax-init.d.20040304.diff, not on top of it.

Created an attachment (id=26864) [details]
pax-conf.d.20040304.1.diff

Hey it worked for wine, I didn't know I missed the ${PEMISC} -> ${PE_misc}
thing.	:(

Note to self: Add this to portage this week.

Created an attachment (id=32796) [details]
conf.d/chpax

This is NOT a patch!  It is a replacement.

This one fixes up some more java, and it also makes Firefox like plug-ins.

DETAILS:  firefox wants +m to get an executable stack for flash 7 and for Java.
 I'll save the expletives; let's just say I'm not pleased.  This file needs to
shrink.

Created an attachment (id=32797) [details]
init.d/chpax

This chpax script allows an unverbose mode.

DETAILS:  It appears that `eval foo-*{,/bin}/biz` may evaluate to "foo-1/biz
foo-1/bin/biz foo-*/biz foo-*/bin/biz".  Obviously, the literal * containing
filenames won't be there.  Moreover, any entries for packages not installed on
the system will also not be there.

The effect is that chpax becomes very noisy and spews several screenfulls of
data about java, wine, and everything else.  This takes up enough cycles (as
screen printing is very expensive) to cause the script to run for several
seconds.

Redirecting the output to /dev/null resulted in the running time being reduced
to several miliseconds instead of several seconds.  The verbose mode is still
available for maintainers.

commited to portage.

gpg signed and commited that update you mentioned on irc. Ready to close this
bug?

changing resolution to FIXED

Created an attachment (id=34309) [details]
conf.d/chpax

New chpax for 2004 JUN 27

Any problems, bug me with the package that's broke.

Updated the conf.d in portage.

Created an attachment (id=35333) [details]
init.d/chpax

This one is a bit smarter with applying flags; it checks to see if the file
exists first and is executable.  It's also more verbose if VERBOSE=yes

Works for me.

Created an attachment (id=35335) [details]
conf.d/chpax

Added mozilla-bin to have -m, so that plugins work in mozilla and not just
firefox.

Prettied it up; most stuff is separated by ${app} so it looks more
straightforward.  There's ~8 apps like this, and ~6 that are in ${PSE_misc}; so
we have 14 packages that we're concerned with.

Really it's 16, since ${x11} is xorg/xfree, and ${mozilla} is mozilla/firefox,
and ${xine} is xine/gxine.  If you count individual javas, it's a few more.

Reopening until the new version gets committed.

Created an attachment (id=35971) [details]
conf.d/chpax

This one includes mono as was discussed on the channel.  Thanks for tracking
these down to Mystilleef.

(From update of attachment 35333 [details])
In portage

Created an attachment (id=36343) [details]
init.d/pax

This one does two new things.

1)  It lets me tell execstack to clear the executable flag on things; this is
probably related to some glibc bug nobody ever filed a bug on where it honors
whatever `execstack -c` turns off.  You'll need to merge sys-devel/prelink to
get execstack installed.
2)  It takes ZERO_ON_START=yes to mean that you want to zero flags immediately
before applying new ones.  This is a good thing; it'll take the old -m off xmms
and mozilla, and add -E to xmms

As well, it uses -E instead of -e for "TRAMPOLINE_EXEMPT"; -e is the default
(restrictive) mode.  This was a bug I hadn't noticed because i'd never needed
it; but now I -E mark xmms (for now) due to an alsalib issue.

Created an attachment (id=36344) [details]
conf.d/pax

This configuration file has a few things that need execstack cleared (doesn't
clear it on alsa though; although xmms has -E), and as well takes firefox and
Mozilla out of the -m setting.	This leaves xmms for now, as we don't execstack
alsalib yet for fear of other breakage.

When a new version of alsa that doesn't need trampolines comes out, xmms will
lose its -E and -m markings.  For now, you should be wary of the -m marking on
xmms in combination with streaming audio.

Skilled users may remove the executable stack flag from alsalib and mark xmms
-zE if they are really concerned about streaming media being used to exploit
xmms.  Alternatively, something else could be used to stream media; or the OSS,
esd, or aRts output plugin could be used.

As a side-note, I changed /etc/*.d/chpax to /etc/*.d/pax here.  This will
require that the chpax ebuild be changed:

    insinto /etc/conf.d
    newins ${FILESDIR}/pax-conf.d chpax
    exeinto /etc/init.d
    newexe ${FILESDIR}/pax-init.d chpax

becomes

    insinto /etc/conf.d
    newins ${FILESDIR}/pax-conf.d pax
    exeinto /etc/init.d
    newexe ${FILESDIR}/pax-init.d pax

This should be considered before actually DOING this, because as soon as the
name of the init script is changed, everyone with chpax added to any given
runlevel will lose that setting.

as a temporary fix, I'll try to get an ebuild up which makes symlinks from
chpax->pax, if you want; of course, it's not really necessary, just a semantics
change because it's more paxctl than chpax, and now uses execstack as well' and
God knows what else we'll need in here in the future.

Created an attachment (id=36433) [details]
conf.d/pax

This is mostly due to a bug/issue in libGL.so.1 affecting Mesa in Xorg and
XFree86.  The nature of this bug is that for some reason libGL sets off PaX;
but adding -E to the binaries (trampoline emulation) doesn't solve the problem,
indicating that this is probably not a trampolining issue.  I unfortunately had
to -m a lot of stuff.

 - Blender and bzFlag get -m instead of -psem
 - All xscreensavers get -m; various GL xscreensavers need -m to function

Also, the execstack stuff was made togglable from conf.d/pax when execstack
(prelink) is merged.

 - SET_NO_EXECSTACK="yes" will cause execstack to be run against NO_EXECSTACK
binaries

Created an attachment (id=36436) [details]
init.d/pax

The execstack stuff was made togglable from conf.d/pax when execstack (prelink)
is merged.

 - SET_NO_EXECSTACK="yes" will cause execstack to be run against NO_EXECSTACK
binaries

I hope this will make the addition of execstack commands from the previous
update less intrusive.	These can be removed if/when stable glibc is fixed to
*ignore* the PT_GNU_STACK bit.

I'm not forcing execstack/prelink on anybody. 
Reopen when the script does not use it.

Created an attachment (id=37155) [details]
init.d/pax

Removed execstack stuff.

Also, TRAMPOLINE_EXEMPT became EMUTRAMP_ENABLED for semantics.

Created an attachment (id=37156) [details]
conf.d/pax

Took out execstack stuff, added zsnes needing mprotect().

This file is made assuming that on x86 a PT_GNU_STACK marked lib (such as a
mozilla plug-in) won't force certain apps (mozilla) to either give a PROT_EXEC
stack or fail to load the plug-in.  Mozilla and Firefox are no longer fully
exploitable; the stack is non-executable.

The following was conducted using tuxnes 0.75
Executing it results in the following:

urbanfox@Rebel urbanfox $ /usr/bin/tuxnes roms/NES/ROMs/Dragonwarrior.nes 
Killed

For a while I was convinced it was a problem with my CFLAGS, however, after trying to build it entirely unoptimized, I finally remember I had PaX running on my system, so I run dmesg to see if that's the problem, and surely enough: 
 
PAX: execution attempt in: <anonymous mapping>, 12000000-12800000 12000000
PAX: terminating task: /usr/bin/tuxnes(tuxnes):7865, uid/euid: 1000/1000, PC: 12000000, SP: 5dd7bb4c
PAX: bytes at PC: 83 c6 02 83 0d 18 96 50 08 04 8b 1d 5c 00 51 08 83 c6 06 50 
PAX: bytes at SP: 0804f76b 0000ffd8 0804be54 00000004 00000032 ffffffff 00000000 0000431e 2377a740 5dd7bbb0 236fc52c 2377a8e0 2398d260 00000001 5dd7bdbc 00000000 08074648 00000001 00000000 00000000 

chpax -psem /usr/bin/tuxnes seems to fix the problem. I also have execution problems with /usr/games/bin/nestra, but that should come as no surprise seeing as tuxnes is based off of nestra. chpax -psem seems to fix that as well.

none of the java=".."-lines matchen on sun-j2sdk. The correct path is
/opt/sun-j2sdk.
Possible lines are

java="/opt/*-{j{,2s}dk-*/{,jre/},jre-*/}bin/*"
java=/opt/{blackdown-{jdk-*/{,jre/},jre-*/}bin
/{java{,_vm,c},keytool,kinit,klist,ktab,orbd,policytool,rmi{d,registry},servertool,tnameserv,*},sun-j2sdk-*/{,jre/}bin/*"

With current chpax (0.7) wine is not functional unless I issue 
 
paxctl -psmxer `which wine-preloader` 
 
as root. 
 
Could this be included into the default-config, if it isn't already?