Created attachment 331412 [details] oracle-jdk-bin-1.7.0.9-build.log 1. emerge sys-apps/elfix-0.6.0 2. override pax-utils.eclass with https://431092.bugs.gentoo.org/attachment.cgi?id=329156 3. set PAX_MARKINGS="XT PT" 4. emerge dev-java/oracle-jdk-bin-1.7.0.9, and then PT PaX marking -Cm fails. emerge --info elfix oracle-jdk-bin Portage 2.2.0_alpha144 (hardened/linux/amd64/selinux, gcc-4.7.2, glibc-2.16.0, 3.6.9-pax-lto.x86_64 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.6.9-pax-lto.x86_64-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9300_@_2.50GHz-with-gentoo-2.2 Timestamp of tree: Tue, 04 Dec 2012 15:15:01 +0000 ld GNU gold (GNU Binutils 2.23.1) 1.11 ccache version 3.1.8 [disabled] app-shells/bash: 4.2_p39 dev-java/java-config: 2.1.12 dev-lang/python: 2.7.3-r2, 3.2.3-r1, 3.3.0 dev-util/ccache: 3.1.8 dev-util/cmake: 2.8.10.2 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.6 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.5 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3, 4.7.2 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo systemd hardened-dev gnome custom Installed sets: @local-protected ACCEPT_KEYWORDS="amd64 x86 ~amd64 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-Wall -Wextra -march=native -pipe -O3 -fno-tree-vectorize -frecord-gcc-switches" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions /var/bind" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-Wall -Wextra -march=native -pipe -O3 -fno-tree-vectorize -frecord-gcc-switches" DISTDIR="/usr/local/portage/distfiles" FCFLAGS="-Wall -Wextra -march=native -pipe -O3 -fno-tree-vectorize -frecord-gcc-switches" FEATURES="assume-digests binpkg-logs buildpkg collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox selinux sesandbox sfperms split-elog split-log strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr" FFLAGS="-Wall -Wextra -march=native -pipe -O3 -fno-tree-vectorize -frecord-gcc-switches" GENTOO_MIRRORS="http://mirrors.163.com/gentoo http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--icf=safe" MAKEOPTS="V=1 -j10" PKGDIR="/usr/local/portage/packages-amd64" PORTAGE_BZIP2_COMMAND="lbzip2" PORTAGE_COMPRESS="xz" PORTAGE_COMPRESS_FLAGS="-9ef" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--ipv4" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/systemd /var/lib/layman/hardened-development /var/lib/layman/gnome /usr/local/portage" SYNC="rsync://mirrors.ustc.edu.cn/gentoo-portage" USE="X acl alsa amd64 audit bash-completion berkdb bzip2 c++0x cairo caps cli cracklib crypt custom-cflags cxx dbus dri ffmpeg gdbm gmp gnome gpm gtk gtk3 hardened iconv icu ipv6 jit jpeg jpeg2k justify lzma mmx modules mudflap multilib ncurses nls nptl open_perms opengl openmp orc pam pax_kernel pcre png pppd pulseaudio qt4 readline selinux session sse sse2 ssl svg systemd tcpd threads tiff udev unicode urandom vim-syntax xattr xinetd zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="bootchart btrfs caps dmsquash-live gensplash livenet lvm nfs ssh-client syslog systemd" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US zh zh_CN" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="x86_64 arm mips64el ppc64" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nouveau nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, USE_PYTHON ================================================================= Package Settings ================================================================= sys-apps/elfix-0.6.0 was built with the following: USE="(multilib) ptpax (selinux) xtpax -test" dev-java/oracle-jdk-bin-1.7.0.9 was built with the following: USE="X alsa fontconfig (multilib) nsplugin pax_kernel (selinux) source -derby -doc -examples -jce"
(In reply to comment #0) > Created attachment 331412 [details] > oracle-jdk-bin-1.7.0.9-build.log > > 1. emerge sys-apps/elfix-0.6.0 > 2. override pax-utils.eclass with > https://431092.bugs.gentoo.org/attachment.cgi?id=329156 > 3. set PAX_MARKINGS="XT PT" > 4. emerge dev-java/oracle-jdk-bin-1.7.0.9, and then PT PaX marking -Cm fails. This is fixed with elfix-0.8.1. For more information, see http://www.gentoo.org/proj/en/hardened/pax-migrate-xattr.xml http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml I removed 0.6.0 so this won't be repeated. Can you test and reopen this bug if it happens for either 0.7.0 (stable) or 0.8.1 (next candidate).
(In reply to comment #1) > (In reply to comment #0) > > Created attachment 331412 [details] > > oracle-jdk-bin-1.7.0.9-build.log > > > > 1. emerge sys-apps/elfix-0.6.0 > > 2. override pax-utils.eclass with > > https://431092.bugs.gentoo.org/attachment.cgi?id=329156 > > 3. set PAX_MARKINGS="XT PT" > > 4. emerge dev-java/oracle-jdk-bin-1.7.0.9, and then PT PaX marking -Cm fails. > > This is fixed with elfix-0.8.1. For more information, see > > http://www.gentoo.org/proj/en/hardened/pax-migrate-xattr.xml > > http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml > > I removed 0.6.0 so this won't be repeated. Can you test and reopen this bug > if it happens for either 0.7.0 (stable) or 0.8.1 (next candidate). I’m very sorry I’m late. dev-java/oracle-jdk-bin still fails to emerge with elfix-0.8.1 and hardened-development/eclass/pax-utils.eclass!
Created attachment 337732 [details] oracle-jdk-bin-1.7.0.11-build.log
paxctl-ng -Cm binary paxctl-ng -ze binary doesn't work.(In reply to comment #1) > (In reply to comment #0) > > Created attachment 331412 [details] > > oracle-jdk-bin-1.7.0.9-build.log > > > > 1. emerge sys-apps/elfix-0.6.0 > > 2. override pax-utils.eclass with > > https://431092.bugs.gentoo.org/attachment.cgi?id=329156 > > 3. set PAX_MARKINGS="XT PT" > > 4. emerge dev-java/oracle-jdk-bin-1.7.0.9, and then PT PaX marking -Cm fails. > > This is fixed with elfix-0.8.1. For more information, see > > http://www.gentoo.org/proj/en/hardened/pax-migrate-xattr.xml > > http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml > > I removed 0.6.0 so this won't be repeated. Can you test and reopen this bug > if it happens for either 0.7.0 (stable) or 0.8.1 (next candidate). paxctl-ng -Cm binary paxctl-ng -ze binary doesn't work.
> paxctl-ng -Cm binary > paxctl-ng -ze binary > > doesn't work. Correct, the flag combination Cm and ze are incorrect. According to the help: paxctl-ng -PpEeMmRrSs|-Z|-z [-L|-l] [-v] ELF ^ ^ these are or's So either -e or -z but not both. So the problem comes in java-vm_set-pax-markings() where we have: local pax_markings="C" local pax_markings+="m" use x86 && pax_markings+="sp" pax-mark ${pax_markings} $(list-paxables "${executables[@]}") This should be changed to pax-mark C $(list-paxables "${executables[@]}") local pax_markings="m" use x86 && pax_markings+="sp" pax-mark ${pax_markings} $(list-paxables "${executables[@]}") This will work for either paxctl-ng or paxctl in case the eclass has to fall back. I see where the Cm combo is coming in but where is the ze encountered? BTW, I'd recommend switching from C to c. Does java need GNU_STACK to run correctly, or can it be converted ti a PAX_FLAGS?
(In reply to comment #5) > use x86 && pax_markings+="sp" maybe i'm forgetting something here, but why does java need pageexec/segmexec (i.e., just the basic non-exec page stuff) off? if that were true, it should fail to run on vanilla as well on NX capable CPUs... now i do have memories that some very old (read: decade+) versions of the SUN JVM had some FPU init code in a .data (and hence non-executable) segment, but surely nothing like that would apply to modern versions? > BTW, I'd recommend switching from C to c. Does java need GNU_STACK to run > correctly, or can it be converted ti a PAX_FLAGS? nothing needs GNU_STACK under PaX (or anywhere else either IMHO ;), dependning on the app/problem, you either want MPROTECT off or EMUTRAMP on.
The 'C' was added on request of the the hardened team. Can be changed again if desired. Originally only 'm' was used. 'sp' was added to x86 for heap sizes over ~800Mb.
(In reply to comment #7) > Originally only 'm' was used. 'sp' was added to x86 for heap sizes over > ~800Mb. why, what happens when the heap reaches 800MB? is there some bugreport on it? or a reproducible test?
(In reply to comment #8) > (In reply to comment #7) > > Originally only 'm' was used. 'sp' was added to x86 for heap sizes over > > ~800Mb. > > why, what happens when the heap reaches 800MB? is there some bugreport on > it? or a reproducible test? bug 389751, there are more that I probably can dig up in our bugzilla if needed.
(In reply to comment #5) > > paxctl-ng -Cm binary > > paxctl-ng -ze binary > > > > doesn't work. > > Correct, the flag combination Cm and ze are incorrect. According to the > help: > > > paxctl-ng -PpEeMmRrSs|-Z|-z [-L|-l] [-v] ELF > ^ ^ > these are or's > > So either -e or -z but not both. > > So the problem comes in java-vm_set-pax-markings() where we have: > > local pax_markings="C" > local pax_markings+="m" > use x86 && pax_markings+="sp" > pax-mark ${pax_markings} $(list-paxables "${executables[@]}") > > This should be changed to > > pax-mark C $(list-paxables "${executables[@]}") > > local pax_markings="m" > use x86 && pax_markings+="sp" > pax-mark ${pax_markings} $(list-paxables "${executables[@]}") > > This will work for either paxctl-ng or paxctl in case the eclass has to fall > back. > > I see where the Cm combo is coming in but where is the ze encountered? find /usr/portage/ -type f | xargs grep -Hn --color 'pax-mark.*\(Cm\|ze\)' /usr/portage/net-mail/notmuch/ChangeLog:222: Combined pax-mark flags -z and -e into -ze, because pax-mark interpreted later /usr/portage/net-mail/notmuch/notmuch-0.10.2-r3.ebuild:113: pax-mark -ze notmuch /usr/portage/net-mail/notmuch/notmuch-0.11.1-r3.ebuild:109: pax-mark -ze notmuch /usr/portage/net-mail/notmuch/notmuch-0.12.ebuild:102: pax-mark -ze notmuch /usr/portage/net-mail/notmuch/notmuch-0.13.1.ebuild:114: pax-mark -ze notmuch /usr/portage/net-mail/notmuch/notmuch-0.14-r1.ebuild:115: pax-mark -ze notmuch /usr/portage/net-mail/notmuch/notmuch-0.15.1.ebuild:135: pax-mark -ze notmuch /usr/portage/net-mail/notmuch/notmuch-0.15.ebuild:135: pax-mark -ze notmuch /usr/portage/net-im/skype/skype-2.2.0.35-r99.ebuild:110: pax-mark Cm "${ED}"/opt/skype/skype || die /usr/portage/net-im/skype/skype-4.0.0.8-r1.ebuild:86: pax-mark Cm "${ED}"/opt/bin/${PN} || die /usr/portage/net-im/skype/skype-4.1.0.20.ebuild:68: pax-mark Cm "${ED}"/opt/bin/${PN} || die /usr/portage/media-gfx/darktable/darktable-1.1.2-r1.ebuild:95: pax-mark Cm "${ED}"/usr/bin/${PN} || die /usr/portage/media-gfx/darktable/darktable-1.1.2.ebuild:95: pax-mark Cm "${ED}"/usr/bin/${PN} || die /usr/portage/media-gfx/darktable/darktable-9999.ebuild:95: pax-mark Cm "${ED}"/usr/bin/${PN} || die
(In reply to comment #10) > (In reply to comment #5) > > > paxctl-ng -Cm binary > > > paxctl-ng -ze binary > > > > > > doesn't work. > > > > Correct, the flag combination Cm and ze are incorrect. According to the > > help: > > > > > > paxctl-ng -PpEeMmRrSs|-Z|-z [-L|-l] [-v] ELF > > ^ ^ > > these are or's > > > > So either -e or -z but not both. > > > > So the problem comes in java-vm_set-pax-markings() where we have: > > > > local pax_markings="C" > > local pax_markings+="m" > > use x86 && pax_markings+="sp" > > pax-mark ${pax_markings} $(list-paxables "${executables[@]}") > > > > This should be changed to > > > > pax-mark C $(list-paxables "${executables[@]}") > > > > local pax_markings="m" > > use x86 && pax_markings+="sp" > > pax-mark ${pax_markings} $(list-paxables "${executables[@]}") > > > > This will work for either paxctl-ng or paxctl in case the eclass has to fall > > back. > > > > I see where the Cm combo is coming in but where is the ze encountered? > > find /usr/portage/ -type f | xargs grep -Hn --color 'pax-mark.*\(Cm\|ze\)' > /usr/portage/net-mail/notmuch/ChangeLog:222: Combined pax-mark flags -z and > -e into -ze, because pax-mark interpreted later > /usr/portage/net-mail/notmuch/notmuch-0.10.2-r3.ebuild:113: pax-mark -ze > notmuch > /usr/portage/net-mail/notmuch/notmuch-0.11.1-r3.ebuild:109: pax-mark -ze > notmuch > /usr/portage/net-mail/notmuch/notmuch-0.12.ebuild:102: pax-mark -ze notmuch > /usr/portage/net-mail/notmuch/notmuch-0.13.1.ebuild:114: pax-mark -ze notmuch > /usr/portage/net-mail/notmuch/notmuch-0.14-r1.ebuild:115: pax-mark -ze > notmuch > /usr/portage/net-mail/notmuch/notmuch-0.15.1.ebuild:135: pax-mark -ze notmuch > /usr/portage/net-mail/notmuch/notmuch-0.15.ebuild:135: pax-mark -ze notmuch > /usr/portage/net-im/skype/skype-2.2.0.35-r99.ebuild:110: pax-mark Cm > "${ED}"/opt/skype/skype || die > /usr/portage/net-im/skype/skype-4.0.0.8-r1.ebuild:86: pax-mark Cm > "${ED}"/opt/bin/${PN} || die > /usr/portage/net-im/skype/skype-4.1.0.20.ebuild:68: pax-mark Cm > "${ED}"/opt/bin/${PN} || die > /usr/portage/media-gfx/darktable/darktable-1.1.2-r1.ebuild:95: pax-mark Cm > "${ED}"/usr/bin/${PN} || die > /usr/portage/media-gfx/darktable/darktable-1.1.2.ebuild:95: pax-mark Cm > "${ED}"/usr/bin/${PN} || die > /usr/portage/media-gfx/darktable/darktable-9999.ebuild:95: pax-mark Cm > "${ED}"/usr/bin/${PN} || die Can you find all combinations of flags given to pax-mark and see which break against paxctl-ng. I can either fix this in the eclass or I can fix it in paxctl-ng. If its just Cm and ze I'll just do the eclass fix.
Created attachment 337882 [details] 'pax-mark \(Cm\|cm\|-ze\|-PemRxS\)' > Can you find all combinations of flags given to pax-mark and see which break > against paxctl-ng. I can either fix this in the eclass or I can fix it in > paxctl-ng. If its just Cm and ze I'll just do the eclass fix. pax-mark Cm pax-mark cm pax-mark -ze pax-mark -PemRxS (obsolete flag 'x') That's all combinations of flags which may break against paxctl-ng.
(In reply to comment #12) > Created attachment 337882 [details] > 'pax-mark \(Cm\|cm\|-ze\|-PemRxS\)' > > > Can you find all combinations of flags given to pax-mark and see which break > > against paxctl-ng. I can either fix this in the eclass or I can fix it in > > paxctl-ng. If its just Cm and ze I'll just do the eclass fix. > > pax-mark Cm > pax-mark cm > pax-mark -ze > pax-mark -PemRxS (obsolete flag 'x') > > That's all combinations of flags which may break against paxctl-ng. Yeah I got this too. The issue really is just the C, c and z flags combo. This is easily fixed in the ebuild. I'll have another go at the eclass tomorrow. Thanks for pointing this out.
(In reply to comment #13) > (In reply to comment #12) > > Created attachment 337882 [details] > > 'pax-mark \(Cm\|cm\|-ze\|-PemRxS\)' > > > > > Can you find all combinations of flags given to pax-mark and see which break > > > against paxctl-ng. I can either fix this in the eclass or I can fix it in > > > paxctl-ng. If its just Cm and ze I'll just do the eclass fix. > > > > pax-mark Cm > > pax-mark cm > > pax-mark -ze > > pax-mark -PemRxS (obsolete flag 'x') > > > > That's all combinations of flags which may break against paxctl-ng. > > Yeah I got this too. The issue really is just the C, c and z flags combo. > This is easily fixed in the ebuild. I'll have another go at the eclass > tomorrow. Thanks for pointing this out. May I add, as a user of pax-mark, all I want is to specify the flags only, which type of markings(ea,pt,xt) and how they are applied shouldn't be my concern. So C should have never been required. The pax-utils.eclass should know how to handle the that.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Created attachment 337882 [details] > > > 'pax-mark \(Cm\|cm\|-ze\|-PemRxS\)' > > > > > > > Can you find all combinations of flags given to pax-mark and see which break > > > > against paxctl-ng. I can either fix this in the eclass or I can fix it in > > > > paxctl-ng. If its just Cm and ze I'll just do the eclass fix. > > > > > > pax-mark Cm > > > pax-mark cm > > > pax-mark -ze > > > pax-mark -PemRxS (obsolete flag 'x') > > > > > > That's all combinations of flags which may break against paxctl-ng. > > > > Yeah I got this too. The issue really is just the C, c and z flags combo. > > This is easily fixed in the ebuild. I'll have another go at the eclass > > tomorrow. Thanks for pointing this out. > > May I add, as a user of pax-mark, all I want is to specify the flags only, > which type of markings(ea,pt,xt) and how they are applied shouldn't be my > concern. So C should have never been required. The pax-utils.eclass should > know how to handle the that. Agreed on the C. It is useless for XATTR_PAX markings and potentially dangerous for PT_PAX. I'm thinking of how to implement this as cleanly as possible in the eclass.
(In reply to comment #15) > Agreed on the C. It is useless for XATTR_PAX markings and potentially > dangerous for PT_PAX. I'm thinking of how to implement this as cleanly as > possible in the eclass. why don't you just add -cC automatically to the paxctl cmdline? it'll do the right thing, that is, progressively try methods to establish PT_PAX_FLAGS.
(In reply to comment #9) > (In reply to comment #8) > > why, what happens when the heap reaches 800MB? is there some bugreport on > > it? or a reproducible test? > > bug 389751, there are more that I probably can dig up in our bugzilla if > needed. so it's a problem if running out of the userland address space, and i'm afraid disabling SEGMEXEC and PAGEEXEC won't solve anything there. sure, SEGMEXEC halves the address space so you can get back some of it by disabling it, but PAGEEXEC runs with the normal linux address space size and disabling it won't change anything. not to mention that you can of course try to run with a big enough heap that won't fit the normal address space (3GB) either, then what? disable the kernel? ;) in any case, this has nothing to do with security and therefore paxctl -sp should not be done in the ebuild. instead warn users about the fact that SEGMEXEC halves the address space (something they should know already as it's documented) and that even without it there're limits to it so they should run a 64 bit version of java if they have such requirements for the java heap.
(In reply to comment #17) > (In reply to comment #9) > > (In reply to comment #8) > > > why, what happens when the heap reaches 800MB? is there some bugreport on > > > it? or a reproducible test? > > > > bug 389751, there are more that I probably can dig up in our bugzilla if > > needed. > > so it's a problem if running out of the userland address space, and i'm > afraid disabling SEGMEXEC and PAGEEXEC won't solve anything there. sure, > SEGMEXEC halves the address space so you can get back some of it by > disabling it, but PAGEEXEC runs with the normal linux address space size and > disabling it won't change anything. not to mention that you can of course > try to run with a big enough heap that won't fit the normal address space > (3GB) either, then what? disable the kernel? ;) > The point being, twice as much is about the limit for jvm heap size on x86, with or without pax. > in any case, this has nothing to do with security and therefore paxctl -sp > should not be done in the ebuild. Here you lost me, we disable security features because they cause bugs / make a working system impossible. > instead warn users about the fact that > SEGMEXEC halves the address space (something they should know already as > it's documented) and that even without it there're limits to it so they > should run a 64 bit version of java if they have such requirements for the > java heap. Icedtea not being able to build itself is obviously not an option and so disabling SEGMEXEC stays. ;) Disabling PAGEEXEC was suggested a few times in different bugs as I recall and finally signed off by zorry in #gentoo-hardened. If it shouldn't be required, it of course can be dropped. Note: for testing, the icedtea build files need to be patched or the results will be screwed. Note 2: the regular bug reports of x86 hardened users for different jvms stopped when 'sp' was added.
(In reply to comment #18) > The point being, twice as much is about the limit for jvm heap size on x86, > with or without pax. so why do you disable PaX features then if PaX per se has nothing to do with the problem? ;) > > in any case, this has nothing to do with security and therefore paxctl -sp > > should not be done in the ebuild. > > Here you lost me, we disable security features because they cause bugs / > make a working system impossible. ok, let me try it from another angle ;). in case you're not aware, on i386 kernels the userland/kernel address space split can be configured, userland can be 1/2/3GB (and some variations of them) in size. as you can guess, choosing anything but the default 3GB would result in the exact same symptoms for the java heap size problem as with SEGMEXEC. yet you're not forbidding these kernel options nor do you provide a runtime workaround (there isn't one). i call that an inconsistency in your argument and ask again why you disable SEGMEXEC when the problem is not its existence but the collision between user requirements and reality? the solution for that is not blindly disabling SEGMEXEC for *everyone* (i.e., even those not running into this problem), but educating the users to choose their poison^Wkernel features carefully. > Icedtea not being able to build itself is obviously not an option and so > disabling SEGMEXEC stays. ;) then disable SEGMEXEC for *building* icedtea only, not for everyone permanently. and also tell me how you handle the other CONFIG_VMSPLIT_* options 'cos now i'm really curious ;). if the answer is 'we do not' then please apply that to SEGMEXEC as well. > Disabling PAGEEXEC was suggested a few times in different bugs as I recall > and finally signed off by zorry in #gentoo-hardened. If it shouldn't be > required, it of course can be dropped. care to show me where this happened? the only reason i'd disable PAGEEXEC is if i had a (now) really old CPU without NX support where the old PAGEEXEC method is less efficient than SEGMEXEC. > Note 2: the regular bug reports of x86 hardened users for different jvms > stopped when 'sp' was added. i can produce bug reports with sufficiently big heap sizes (and i didn't even mention that ASLR can cause it randomly too) even with SEGMEXEC/PAGEEXEC disabled. what will you do about CONFIG_VMSPLIT_* again? ;)
(In reply to comment #19) > (In reply to comment #18) > > The point being, twice as much is about the limit for jvm heap size on x86, > > with or without pax. > > so why do you disable PaX features then if PaX per se has nothing to do with > the problem? ;) Don't twist the words in my mouth, you know what I mean.
> > so why do you disable PaX features then if PaX per se has nothing to do with > > the problem? ;) > > Don't twist the words in my mouth, you know what I mean. http://en.wikipedia.org/wiki/Emoticon now how about responding to the real issues i raised?
(In reply to comment #21) > now how about responding to the real issues i raised? 'm' isn't needed either, a user can just use the interpreter mode. Seriously you get as much security by default as doesn't hurt. The markings are properly logged and a user has the tools to change what he isn't happy about and we can close resulting bugs as WONTFIX. (In reply to comment #19) > (In reply to comment #18) > > Icedtea not being able to build itself is obviously not an option and so > > disabling SEGMEXEC stays. ;) > > then disable SEGMEXEC for *building* icedtea only, not for everyone > permanently. and also tell me how you handle the other CONFIG_VMSPLIT_* > options 'cos now i'm really curious ;). if the answer is 'we do not' then > please apply that to SEGMEXEC as well. It's not the only package that needs such a heap size to be built.
(In reply to comment #14) > May I add, as a user of pax-mark, all I want is to specify the flags only, > which type of markings(ea,pt,xt) and how they are applied shouldn't be my > concern. So C should have never been required. The pax-utils.eclass should > know how to handle the that. I've improved the logic in the pax-utils.eclass. I've added a function which sanitizes the flags. It only permits the flags themselves and -z to fall back on the default. Also, since -C -c is still a reality with is, when performing PT_PAX markings, paxctl is attempted before other utilities and progressively tries to first just do them markings, then -c and do the markings and finally -C and do the markings. @Alphat-PC and other, can you please test the hardened-dev overlay eclass at http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=blob;f=eclass/pax-utils.eclass;h=fdc7769e014e3e4de8ebd0ae8896a1a83dc47c03;hb=3a2cbaec20cf614ec0dfbf7a6c0d3cedff412b5b
(In reply to comment #23) > (In reply to comment #14) > > > May I add, as a user of pax-mark, all I want is to specify the flags only, > > which type of markings(ea,pt,xt) and how they are applied shouldn't be my > > concern. So C should have never been required. The pax-utils.eclass should > > know how to handle the that. > > I've improved the logic in the pax-utils.eclass. I've added a function > which sanitizes the flags. It only permits the flags themselves and -z to > fall back on the default. > > Also, since -C -c is still a reality with is, when performing PT_PAX > markings, paxctl is attempted before other utilities and progressively tries > to first just do them markings, then -c and do the markings and finally -C > and do the markings. > > @Alphat-PC and other, can you please test the hardened-dev overlay eclass at > > http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=blob; > f=eclass/pax-utils.eclass;h=fdc7769e014e3e4de8ebd0ae8896a1a83dc47c03; > hb=3a2cbaec20cf614ec0dfbf7a6c0d3cedff412b5b A bashisms version: --- pax-utils.eclass.orig 2013-02-10 02:17:21.651505480 +0000 +++ pax-utils.eclass 2013-02-10 06:50:25.582657018 +0000 @@ -64,13 +64,8 @@ PAX_MARKINGS=${PAX_MARKINGS:="PT XT"} # 3. z is allowed for the default # sanitize-flags() { - local flags=$1 - local clean="" - - for f in z P p E e M m R r S s; do - [[ "${flags}" != "${flags/${f}/}" ]] && clean="${clean}${f}" - done - echo "$clean" +# echo "${1//[^zPpEeMmRrSs]}" + echo "${1//[!zPpEeMmRrSs]}" } pax-mark() { @@ -81,7 +76,7 @@ pax-mark() { local xt_fail=0 xt_failures="" # record xattr PAX marking failures local ret=0 # overal return code of this function - flags="$(sanitize-flags $1)" + flags="${1//[!zPpEeMmRrSs]}" shift if has PT ${PAX_MARKINGS}; then
Created attachment 338476 [details, diff] pax-utils.eclass.diff
Created attachment 338480 [details, diff] pax-utils.eclass.diff
(In reply to comment #26) > Created attachment 338480 [details, diff] [details, diff] > pax-utils.eclass.diff Thanks Alphat-PC. I committed this. The original problem in this bug, that eclass/java-vm-2.eclass should not use Cm flag combination has been fixed with our changes to pax-utils.eclass. So, I'm going to close this bug and lets post changes to the parent bug #431092.
