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 attachment 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 attachment 25829 [details, diff] 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 attachment 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 attachment 26077 [details, diff] 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 attachment 26078 [details, diff] 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 attachment 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 attachment 26857 [details, diff] 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 attachment 26858 [details, diff] pax-init.d.20040304.diff This was made along with the above conf.d patch
Created attachment 26860 [details, diff] 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 attachment 26864 [details, diff] 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 35971 [details] conf.d/chpax This one includes mono as was discussed on the channel. Thanks for tracking these down to Mystilleef.
Comment on attachment 35333 [details] init.d/chpax In portage
Created attachment 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 attachment 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 attachment 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 attachment 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 attachment 37155 [details] init.d/pax Removed execstack stuff. Also, TRAMPOLINE_EXEMPT became EMUTRAMP_ENABLED for semantics.
Created attachment 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?
