Hello, this bug is for reference only. Please assign it to the hardened developers and remove the first three sentences of this description. Thank you. -- This bug contains information which packages will be modified to use chpax and the progress of the transition to paxctl or an eclass function. The following is a list of packages containing the word "chpax" in their .ebuild file: app-antivirus/bitdefender-console/bitdefender-console-7.0.1-r1.ebuild app-emulation/emul-linux-x86-java/emul-linux-x86-java-1.5.0.08.ebuild app-office/openoffice-bin/openoffice-bin-2.0.3.ebuild app-office/openoffice-bin/openoffice-bin-2.0.4_rc2.ebuild app-office/openoffice/openoffice-2.0.3.ebuild app-office/openoffice/openoffice-2.0.4_rc1-r1.ebuild dev-java/blackdown-jdk/blackdown-jdk-1.4.2.03-r12.ebuild dev-java/blackdown-jdk/blackdown-jdk-1.4.2.03-r2.ebuild dev-java/blackdown-jdk/blackdown-jdk-1.4.2.03.ebuild dev-java/sun-jdk/sun-jdk-1.4.2.10-r2.ebuild dev-java/sun-jdk/sun-jdk-1.4.2.12-r1.ebuild dev-java/sun-jdk/sun-jdk-1.4.2.12.ebuild dev-java/sun-jdk/sun-jdk-1.5.0.08.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.4.2.10-r2.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.4.2.10.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.4.2.12-r1.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.4.2.12.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.5.0.06-r2.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.5.0.06.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.5.0.07.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.5.0.08-r1.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.5.0.08.ebuild net-im/skype/skype-1.3.0.37.ebuild sys-apps/chpax/chpax-0.7.ebuild sys-apps/gradm/gradm-2.1.5.200504081812.ebuild sys-apps/gradm/gradm-2.1.6.200506131347.ebuild sys-apps/gradm/gradm-2.1.7.200511041858.ebuild sys-apps/gradm/gradm-2.1.8.200601212342-r1.ebuild sys-apps/gradm/gradm-2.1.8.200601212342.ebuild sys-apps/gradm/gradm-2.1.9.200602141850.ebuild sys-boot/grub/grub-0.96-r1.ebuild x11-wm/treewm/treewm-0.4.4.ebuild -Alex
Created attachment 97466 [details, diff] bitdefender-console-7.0.1-r1.ebuild.scanelf.patch adapted and tested on x86 stable chroot -Alex
On a wider note, I'm not convinced it's a good idea that we relax the PaX restrictions automatically; it should be the responsibility of the system owner, not portage.
Created attachment 97475 [details, diff] openoffice-bin-2.0.3.ebuild.scanelf.patch >>> /usr/lib/openoffice/program/libsalhelper3gcc3.so -> libsalhelpergcc3.so.3 * Disabling some PaX restrictions (m) TYPE PAX FILE ET_EXEC PemRxS /usr/lib/openoffice/program/soffice.bin * To start OpenOffice.org, run: * * $ ooffice2 * * Also, for individual components, you can use any of: * * oobase2, oocalc2, oodraw2, oofromtemplate2, ooimpress2, oomath2, * ooweb2 or oowriter2 * * Spell checking is now provided through our own myspell-ebuilds, * if you want to use it, please install the correct myspell package * according to your language needs. >>> Regenerating /etc/ld.so.cache... >>> app-office/openoffice-bin-2.0.3 merged. >>> Recording app-office/openoffice-bin in "world" favorites file...
(In reply to comment #2) > On a wider note, I'm not convinced it's a good idea that we relax the PaX > restrictions automatically; it should be the responsibility of the system > owner, not portage. > Yeah, Kevin, i understand this. But on the other hand the people using portage are expecting to emerge working binaries and telling them that they need to have "extra work" done to the emerged executables before they can use these with a PaX kernel will probably have a negative impact on the performance and acceptance of the overall solution- this is just my opinion and it is still debatable if i am right or not. Also it can be noted that an active grsecurity policy always overrides the flags inside the files. Changing the chpax logic to scanelf is done for a different reason. As to the author of pax, in the future, PaX kernels will not support EI_PAX any more and from then on executables without pax flags inside a PT_PAX_FLAGS program header will not be protected any more. Thus we need to first get rid of chpax and in the second step transform executables to the new PT_PAX_FLAGS layout. -Alex
(In reply to comment #2) > On a wider note, I'm not convinced it's a good idea that we relax the PaX > restrictions automatically; it should be the responsibility of the system > owner, not portage. no, it should not be the responsibility of the user as what the code wants to do is up to the programmer, not the user. so if the code (programmer) does something that is in conflict with a particular PaX feature then there's only one choice: relax the particular PaX feature on the app (the 'alternative' is to not be able to run the app at all), a user can wish all he wants but that won't change the app's code. so the real work is to find out what apps need what relaxation (we already know of many/most i think) and find the best way to apply them under portage.
Created attachment 97477 [details, diff] openoffice-bin-2.0.4_rc2.ebuild.scanelf.patch after unmasking the version in /usr/portage/profiles/package.mask, the ebuild merges fine with the changes: >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. * Disabling some PaX restrictions (m) TYPE PAX FILE ET_EXEC PemRxS /usr/lib/openoffice/program/soffice.bin * To start OpenOffice.org, run: * * $ ooffice2 * * Also, for individual components, you can use any of: * * oobase2, oocalc2, oodraw2, oofromtemplate2, ooimpress2, oomath2, * ooweb2 or oowriter2 * * Spell checking is now provided through our own myspell-ebuilds, * if you want to use it, please install the correct myspell package * according to your language needs. >>> Regenerating /etc/ld.so.cache... >>> app-office/openoffice-bin-2.0.4_rc2 merged.
Created attachment 97479 [details, diff] openoffice-2.0.3.ebuild.scanelf.patch
Created attachment 97480 [details, diff] openoffice-2.0.4_rc1-r1.ebuild.scanelf.patch
(In reply to comment #6) > * Disabling some PaX restrictions (m) > TYPE PAX FILE > ET_EXEC PemRxS /usr/lib/openoffice/program/soffice.bin where does OOo generate code at runtime? does anyone have some PaX logs? or is it java running within the OOo process?
> where does OOo generate code at runtime? does anyone have some PaX logs? or is > it java running within the OOo process? > apocalypse ~ # scanelf -x /usr/lib/openoffice/program/soffice.bin TYPE PAX FILE ET_EXEC PeMRxS /usr/lib/openoffice/program/soffice.bin pappy@apocalypse /tmp/patches $ ooffice2 terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc apocalypse ~ # scanelf -Xxzm /usr/lib/openoffice/program/soffice.bin TYPE PAX FILE ET_EXEC PemRxS /usr/lib/openoffice/program/soffice.bin ... works ... pappy@apocalypse ~ $ uname -a Linux apocalypse 2.6.17.11-grsec #1 Tue Sep 19 13:13:04 CEST 2006 i686 Intel(R) Celeron(R) CPU 2.53GHz GNU/Linux # # Non-executable pages # CONFIG_PAX_NOEXEC=y CONFIG_PAX_PAGEEXEC=y CONFIG_PAX_SEGMEXEC=y # CONFIG_PAX_DEFAULT_PAGEEXEC is not set CONFIG_PAX_DEFAULT_SEGMEXEC=y CONFIG_PAX_EMUTRAMP=y CONFIG_PAX_MPROTECT=y # CONFIG_PAX_NOELFRELOCS is not set CONFIG_PAX_KERNEXEC=y # # Address Space Layout Randomization # CONFIG_PAX_ASLR=y CONFIG_PAX_RANDKSTACK=y CONFIG_PAX_RANDUSTACK=y CONFIG_PAX_RANDMMAP=y CONFIG_PAX_NOVSYSCALL=y
Created attachment 97488 [details, diff] emul linux patch untested, no amd64 arch available here
Created attachment 97489 [details, diff] grub scanelf patch
Created attachment 97490 [details, diff] skype scanelf patch
Created attachment 97491 [details, diff] scanelf migration
Created attachment 97492 [details, diff] scanelf migration
Created attachment 97493 [details, diff] scanelf migration
Created attachment 97494 [details, diff] scanelf migration
Created attachment 97495 [details, diff] /tmp/patches/sun-jre-bin-1.4.2.10.ebuild.scanelf.patch
Created attachment 97496 [details, diff] /tmp/patches/sun-jre-bin-1.4.2.10-r2.ebuild.scanelf.patch
Created attachment 97497 [details, diff] /tmp/patches/sun-jre-bin-1.4.2.12.ebuild.scanelf.patch
Created attachment 97498 [details, diff] /tmp/patches/sun-jre-bin-1.4.2.12-r1.ebuild.scanelf.patch
Created attachment 97499 [details, diff] /tmp/patches/sun-jre-bin-1.5.0.06.ebuild.scanelf.patch
Created attachment 97500 [details, diff] /tmp/patches/sun-jre-bin-1.5.0.06-r2.ebuild.scanelf.patch
Created attachment 97501 [details, diff] /tmp/patches/sun-jre-bin-1.5.0.07.ebuild.scanelf.patch
Created attachment 97502 [details, diff] /tmp/patches/sun-jre-bin-1.5.0.08.ebuild.scanelf.patch
Created attachment 97503 [details, diff] /tmp/patches/sun-jre-bin-1.5.0.08-r1.ebuild.scanelf.patch
So, this is the whole bunch of patches needed for getting rid of chpax doing PaX flags in portage at this moment. No code internally changed: treewm-0.4.4 (only depends on chpax but does not use it). -Alex
* Disabling some PaX restrictions (pemrxs) TYPE PAX FILE ET_EXEC pemrxs /opt/blackdown-jdk-1.4.2.03/bin/jar TYPE PAX FILE ET_EXEC pemrxs /opt/blackdown-jdk-1.4.2.03/bin/javac TYPE PAX FILE ET_EXEC pemrxs /opt/blackdown-jdk-1.4.2.03/bin/java TYPE PAX FILE ET_EXEC pemrxs /opt/blackdown-jdk-1.4.2.03/bin/javah TYPE PAX FILE ET_EXEC pemrxs /opt/blackdown-jdk-1.4.2.03/bin/javadoc TYPE PAX FILE ET_EXEC pemrxs /opt/blackdown-jdk-1.4.2.03/jre/bin/java_vm >>> Regenerating /etc/ld.so.cache... >>> dev-java/blackdown-jdk-1.4.2.03-r12 merged. testing...
One problem with relaxing the restrictions automatically is that it the results are not necessarily static. For example, whether mozilla-firefox needs permissions to be relaxed depends on which plugins are being used. Another example would be all X apps that use GL - whether they need execheap depends on which GL is installed. For apps that use java, it'll depend on whether a JIT JVM is being used or not. That aside, this definitely should be done via an eutil (which are still implemented in eclasses). It could easily be made configurable, so that setting some env vars in make.conf would control how the eutil behaves; e.g. whether it actually sets the flags or just records it somewhere the sysadmin can check. Lastly, does scanelf have the latest stuff from paxctl (i.e. does it have the ability to add the PT header to binaries that don't already have it)?
(In reply to comment #10) > > where does OOo generate code at runtime? does anyone have some PaX logs? or is > > it java running within the OOo process? > > > > apocalypse ~ # scanelf -x /usr/lib/openoffice/program/soffice.bin > TYPE PAX FILE > ET_EXEC PeMRxS /usr/lib/openoffice/program/soffice.bin > > pappy@apocalypse /tmp/patches $ ooffice2 > terminate called after throwing an instance of 'std::bad_alloc' > what(): St9bad_alloc are there any PaX logs (grep PAX /var/log/*)? if not, then the problem is more subtle and could be a bug in OOo rather than interference with PaX. also, do you have USE=java for openoffice? if so, what happens if you try without?
here we go answering the questions: 1) openoffice-bin was emerged with USE="-java" 2) no pax logs The splash screen appears for a short second and then the error message appears: pappy@apocalypse ~ $ ooffice2 terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc I think i can do debugging with the non-binary version of openoffice.org Kevin, to my knowledge scanelf does not contain logic to add PT_PAX_FLAGS headers. But this bug is important nevertheless, because the war is "won on a wider front" :) There can be two or three tools achieving each their own goal: Scanelf replaced chpax because it contains more logic than chpax (which means it can edit PT_PAX_FLAGS headers) The current Gentoo toolchain (binutils) emits PT_PAX_FLAGS to everything it compiles itself. A tool inside portage (yet to be written) can do QA and modify binaries in the install stage automatically that haven't been compiled by Gentoo toolchain. If this tool fails for some reason, then the corresponding debugging and error output can be generated. This tells the user she or he is having binaries without PT_PAX_FLAGS program headers on the system now which is deprecated. The reason for this is that according to pipacs the PaX kernel will be available without EI_PAX modus sooner or later. I think we will find a solution, but the first step, replacing chpax with scanelf, did not put a stone on the road we are travelling. Thanks, Alex
paxctl can already add a PT header if no spare header exists (see paxctl -C). It's just that scanelf is included on all systems by default, as it's used by portage for various QA checks. With regards hiding such details in an eclass, I was thinking initially along the lines of: pax-mark() { local flags fail=0 flags=$1 shift if [[ -x /sbin/chpax ]]; then einfo "Legacy PaX marking $* with ${flags}" /sbin/chpax -${flags} $* || fail=1 fi if [[ -x /sbin/paxctl ]]; then einfo "PT PaX marking $* with ${flags}" /sbin/paxctl -q${flags} $* || /sbin/paxctl -qc${flags} $* || /sbin/paxctl -qC${flags} $* || fail=1 else [[ -x /usr/bin/scanelf ]]; then einfo "PaX marking $* with ${flags}" /usr/bin/scanelf -Xxqz ${flags} $* # need some failure detection here to detect when # scanelf couldn't set the PT flags. else fail=1 fi [[ ${fail} == 1 ]] && ewarn "PaX marking $* with ${flags} failed" return ${fail} } Other possibilities are to control the legacy marking via a make.conf variable (instead of just the presence of /sbin/chpax), and to provide for simply recording the ebuild-recommended PaX settings instead of actually setting them (again controlled via a make.conf variable).
Let me interfere with that last comment please. I think we are mixing up two problems here and trying to make them both be one: - the adjustment of PaX flags necessary for running some binaries under a PaX kernel - the existence of the newer PT_PAX_FLAGS headers Your idea is effective to take care of those executables only which need to be manipulated. But this is not enough. As this does not solve the problem pipacs described earlier: on a good Gentoo box, every executable needs PT_PAX_FLAGS. So here is my wishlist: 1) chpax is deprecated, you do not need it to set flags any more 2) portage should take care in install phase of EVERY executable being PT_PAX_FLAG'ed (whether this is done with paxctl -c, paxctl -C or some new tool) 3) When 2) has done the first job, scanelf is sufficient for getting the other job done. Thanks, Alex
Sorry Alex, I don't see your point in c#33. The toolchain does (and has since before I joined) built everything with a PT_PAX_FLAGS header. The only stuff that needs headers injected are non-Gentoo pre-built binaries. We only need to twiddle binaries for which the default PaX flags are not sufficient. Providing a simple function in an eclass allows us to provide for PaX flag manipulation by ebuilds in a way that allows us to migrate from one tool to another as and when it becomes sensible, without having to hack around in everyone else's ebuilds beyond a one-time touch to replace whatever the ebuilds currently have with calls to the pax-mark() function (plus the necessary inherit - or it could go into eutils.eclass, which might be tidier). The function I suggested sets the EI flags if chpax is installed. This is an easy way to deal with deprecated EI flags. System owners can control whether EI flags are set by installing or not /sbin/chpax - if the system doesn't need EI flags then there's little point having /sbin/chpax installed. It could also be done with a make.conf variable, although I don't think it's worth the effort. Using paxctl as a preference to scanelf for twiddling PT flags is intended, as that's the tool supported for the job by upstream. scanelf provides a fall back should paxctl not be present - note scanelf currently sets both EI flags and PT flags if it can, and you don't get an error if PT flags couldn't be set (since setting EI flags always succeeds). Obviously we can extend scanelf to do more stuff, or do stuff differently - but using the upstream tools by default I think is a good idea regardless.
okay, i got your point. will do. Alex
(In reply to comment #30) > (In reply to comment #10) > > > where does OOo generate code at runtime? does anyone have some PaX logs? or is > > > it java running within the OOo process? > > > > > > > apocalypse ~ # scanelf -x /usr/lib/openoffice/program/soffice.bin > > TYPE PAX FILE > > ET_EXEC PeMRxS /usr/lib/openoffice/program/soffice.bin > > > > pappy@apocalypse /tmp/patches $ ooffice2 > > terminate called after throwing an instance of 'std::bad_alloc' > > what(): St9bad_alloc > > are there any PaX logs (grep PAX /var/log/*)? if not, then the problem is more > subtle and could be a bug in OOo rather than interference with PaX. also, do > you have USE=java for openoffice? if so, what happens if you try without? belated reply, but i finally took a look at OOo and it actually wants to allocate rwx memory to generate code at runtime - nothing to help there (short of rewriting some complex looking system, if at all possible), it needs -m.
For interest, there are a set of bugs on openoffice.org's issue tracker that at least fixed openoffice so it obtains executable heap in a reliable manner. The OOo people went as far as getting openoffice to set heap RW, writing the code in, then setting it RX, which is about as good as it gets on that sort of thing short of eliminating all the run-time code generation: http://www.openoffice.org/issues/show_bug.cgi?id=47132 http://www.openoffice.org/issues/show_bug.cgi?id=61537
