I've tried migration as explained in guide http://www.gentoo.org/proj/en/hardened/pax-migrate-xattr.xml and got few issues. First - when I'm booting kernel with CONFIG_PAX_XATTR_PAX_FLAGS=y (CONFIG_PAX_PT_PAX_FLAGS can be both y or n) Xorg fail to load glx driver. Here is partial diff of Xorg.0.log: 76,80c76,79 < (II) Module glx: vendor="NVIDIA Corporation" < compiled for 4.0.2, module version = 1.0.0 < Module class: X.Org Server Extension < (II) NVIDIA GLX Module 313.26 Wed Feb 27 13:10:40 PST 2013 < Loading extension GLX --- > (EE) Failed to load /usr/lib64/xorg/modules/extensions/libglx.so: /usr/lib64/xorg/modules/extensions/libglx.so: failed to map segment from shared object: Operation not permitted > (II) UnloadModule: "glx" > (II) Unloading glx > (EE) Failed to load module "glx" (loader failed, 7) Yes, I know nvidia-drivers isn't officially supported, but it works with PT_PAX and shouldn't break after migration to XATTR_PAX, isn't it? # paxctl-ng -v /usr/bin/Xorg /usr/bin/Xorg: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: -em-- # paxctl-ng -v /usr/lib{32,64}/opengl/*/lib/libGL.so.{313.26,1.2.0} /usr/lib32/opengl/nvidia/lib/libGL.so.313.26: PT_PAX : not found XATTR_PAX: not found /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0: PT_PAX : -e--- XATTR_PAX: not found /usr/lib64/opengl/nvidia/lib/libGL.so.313.26: PT_PAX : not found XATTR_PAX: not found /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2.0: PT_PAX : -e--- XATTR_PAX: not found # ls -l /usr/lib64/xorg/modules/extensions/libglx.so lrwxrwxrwx 1 root root 50 марта 25 06:26 /usr/lib64/xorg/modules/extensions/libglx.so -> ../../../opengl/nvidia/extensions/libglx.so.313.26 # paxctl-ng -v /usr/lib64/opengl/nvidia/extensions/libglx.so.313.26 /usr/lib64/opengl/nvidia/extensions/libglx.so.313.26: PT_PAX : not found XATTR_PAX: not found I've tried to `paxctl-ng -em` all these libs, but that doesn't helps. Re-emerging nvidia-drivers also won't help. Second - after migrating to XATTR_PAX and switching off CONFIG_PAX_PT_PAX_FLAGS skype works ok. But when later I tried to boot with both CONFIG_PAX_XATTR_PAX_FLAGS=y and CONFIG_PAX_PT_PAX_FLAGS=y (while trying to debug issue with GLX) skype fail to run in this way: $ skype Fatal: QWidget: Must construct a QApplication before a QPaintDevice Aborted # paxctl-ng -v /opt/bin/skype /opt/bin/skype: PT_PAX : -em-- XATTR_PAX: -em-- Re-emerging skype doesn't fix this issue. Next I boot with CONFIG_PAX_PT_PAX_FLAGS=y and CONFIG_PAX_XATTR_PAX_FLAGS=n and skype still fail with same error. I've tried to re-emerge it, but now emerge failed: * PT PaX marking -m with paxctl * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * XT PaX marking -m with paxctl-ng * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * Failed to set XT_PAX markings -m for: * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype After removing repos.conf `emerge skype` works and skype itself works too. Portage 2.1.11.55 (hardened/linux/amd64, gcc-4.6.3, glibc-2.15-r3, 3.8.4-hardened x86_64) ================================================================= System uname: Linux-3.8.4-hardened-x86_64-Intel-R-_Core-TM-_i7-2600K_CPU_@_3.40GHz-with-gentoo-2.1 KiB Mem: 8160180 total, 2902668 free KiB Swap: 4200960 total, 4200960 free Timestamp of tree: Sun, 24 Mar 2013 14:15:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo powerman perl-experimental-snapshots gamerlay hardened-dev local ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/upsmon-usb/EXT/DownOS /opt/upsmon-usb/EXT/JSystem /service /usr/inferno/keydb /usr/inferno/lib /usr/inferno/services /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /var/log /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage-distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y" FCFLAGS="-march=native -O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr" FFLAGS="-march=native -O2 -pipe" GENTOO_MIRRORS="http://gentoo.kiev.ua/ftp/ http://mirror.yandex.ru/gentoo-distfiles/ http://gentoo.iteam.net.ua/" LANG="ru_RU.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j8" PKGDIR="/usr/portage-packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded" 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/powerman /var/lib/layman/perl-experimental-snapshots /var/lib/layman/gamerlay /var/lib/layman/hardened-development /usr/local/portage" SYNC="rsync://rsync.ua.gentoo.org/gentoo-portage" USE="X a52 aac acl alac alsa amd64 avx bash-completion berkdb bzip2 caps cdda cddb cli cracklib crypt cxx dbus dri dts dvb dvd flac fontconfig gdbm gif gnutls gpg gpm hardened iconv icu id3tag idn ipv6 jpeg jpeg2k justify libnotify mac mad matroska mbox mmx mng modules mp3 mpeg mudflap multilib musepack mysql ncurses network-cron nls nptl nsplugin ogg opengl openmp pam pax_kernel pcre perl png qt3support readline session spell sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 svg tcpd theora tiff truetype unicode urandom vdpau vim-syntax vorbis wavpack x264 xattr xosd xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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="log_config vhost_alias autoindex alias rewrite dir deflate filter mime negotiation auth_basic authn_file authz_host authz_user authz_groupfile cgi actions headers env setenvif" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" 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 ru" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="x86_64 i386" QEMU_USER_TARGETS="x86_64 i386" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nvidia nv nouveau" 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, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON
> Yes, I know nvidia-drivers isn't officially supported, but it works with > PT_PAX and shouldn't break after migration to XATTR_PAX, isn't it? There are issue with nvidia-drivers and hardened so expect breakage. Its not that I won't help, but I won't let this be a blocker for progress. > > # paxctl-ng -v /usr/bin/Xorg > /usr/bin/Xorg: > open(O_RDWR) failed: cannot change PT_PAX flags > PT_PAX : -em-- > XATTR_PAX: -em-- > > # paxctl-ng -v /usr/lib{32,64}/opengl/*/lib/libGL.so.{313.26,1.2.0} > /usr/lib32/opengl/nvidia/lib/libGL.so.313.26: > PT_PAX : not found > XATTR_PAX: not found > > /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0: > PT_PAX : -e--- > XATTR_PAX: not found > And the rest ... mark these manually with paxctl-ng. If it won't take xattr pax marking, make sure your filesystem supports xattr. > Second - after migrating to XATTR_PAX and switching off > CONFIG_PAX_PT_PAX_FLAGS skype works ok. But when later I tried to boot with > both CONFIG_PAX_XATTR_PAX_FLAGS=y and CONFIG_PAX_PT_PAX_FLAGS=y (while > trying to debug issue with GLX) skype fail to run in this way: > Unless both pt and xattr pax markings are identical with those settings, you will not get the expected behavior. They are on skype, but what about everything else that skype might depend on. I'm not sure there's anything for me to do here.
(In reply to comment #1) > And the rest ... mark these manually with paxctl-ng. As I said, I've already tried this: >> I've tried to `paxctl-ng -em` all these libs, but that doesn't helps. > If it won't take xattr pax marking, make sure your filesystem supports xattr. Of course it (ext4) support xattr and xattrs enabled in kernel. > Unless both pt and xattr pax markings are identical with those settings, you > will not get the expected behavior. They are identical, I've already shown that: >> # paxctl-ng -v /opt/bin/skype >> /opt/bin/skype: >> PT_PAX : -em-- >> XATTR_PAX: -em-- > They are on skype, but what about everything else that skype might depend on. That's interesting. It's always was unclear for me, how pax flags should be applied to libraries - do we need to paxmark .so libs or not? If libs should be paxmarked, then I wonder how and in which cases. > I'm not sure there's anything for me to do here. If not you, when who? :) Actually, I wanna help debugging these issues, but right now I'm run out of ideas - I don't know pax internals good enough to imagine possible reasons why skype (correctly and identically paxmarked with PT_PAX and XATTR_PAX) working ok with kernel supporting just XATTR_PAX breaks when I boot kernel which support both XATTR_PAX and PT_PAX or only PT_PAX. And even if issue with skype can be explained with broken paxmarking of it's libraries (emul-linux-x86-*), this won't explain issue with GLX module - because I didn't checked skype libs, but I did checked and tried to paxmark all libs which can be related to GLX module (I've listed all of them in my initial report). Or there are should be more libs used while loading GLX module, but I've no idea how to find them.
(In reply to comment #2) > Of course it (ext4) support xattr and xattrs enabled in kernel. What does the following give: paxctl-ng -l ; echo $? > > > I'm not sure there's anything for me to do here. > > If not you, when who? :) In a bug report, I look for what I have to fix at my end. I don't see anything to fix at my end.
# paxctl-ng -l ; echo $? 0
(In reply to comment #4) > # paxctl-ng -l ; echo $? > 0 Try running setfattr -n user.pax.flags -v "e" /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 followed by getfattr -d /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0
for both xorg and skype i'd like to see the PaX status on /proc/pid/status, that's what shows whether MPROTECT was truly disabled on the processes or not. once we know that status, we can debug this further. for nvidia's glx make sure that not only xorg but all other binaries linking to or dlopen'ing it have the same PaX flag relaxation (MPROTECT disabled). also as a sidenote, no PaX markings have any effect on libraries, don't bother with that. this is because we cannot decide (in the kernel) whether a dlopen was intended or unintended (forced by an exploit).
(In reply to comment #6) > also as a sidenote, no PaX markings have any effect on libraries, don't > bother with that. this is because we cannot decide (in the kernel) whether a > dlopen was intended or unintended (forced by an exploit). This is not totally true. We do reverse mark from libraries to executables with a utility revdep-pax. So an "m" on a library tells our utility that any exe linking against it will need "m". Note that this utility is run by the user who must intervene to actually make the markings, so its not going to lead to the exploitable situation above.
(I'm now using PT_PAX-only kernel and has run `migrate -d`, but this shouldn't affect (get|set)fattr, I think. If you need me to run these commands in another setup let me know.) # paxctl-ng -v /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0: PT_PAX : -e--- XATTR_PAX: not found # setfattr -n user.pax.flags -v "e" /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 # getfattr -d /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 getfattr: Removing leading '/' from absolute path names # file: usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 user.pax.flags="e" # paxctl-ng -v /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0: PT_PAX : -e--- XATTR_PAX: -e---
(In reply to comment #8) > (I'm now using PT_PAX-only kernel and has run `migrate -d`, but this > shouldn't affect (get|set)fattr, I think. If you need me to run these > commands in another setup let me know.) > > # paxctl-ng -v /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 > /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0: > PT_PAX : -e--- > XATTR_PAX: not found > # setfattr -n user.pax.flags -v "e" > /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 > # getfattr -d /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 > getfattr: Removing leading '/' from absolute path names > # file: usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 > user.pax.flags="e" > > # paxctl-ng -v /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0 > /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0: > PT_PAX : -e--- > XATTR_PAX: -e--- I looks like paxctl-ng is not working although I can't tell why. Can you post the result of the following: emerge --info elfix
(In reply to comment #9) > I looks like paxctl-ng is not working although I can't tell why. Can you > post the result of the following: Why you think it doesn't work? > emerge --info elfix Portage 2.1.11.55 (hardened/linux/amd64, gcc-4.6.3, glibc-2.15-r3, 3.8.4-hardened x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.8.4-hardened-x86_64-Intel-R-_Core-TM-_i7-2600K_CPU_@_3.40GHz-with-gentoo-2.1 KiB Mem: 8160180 total, 1680164 free KiB Swap: 4200960 total, 4141904 free Timestamp of tree: Mon, 25 Mar 2013 09:15:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo powerman perl-experimental-snapshots gamerlay hardened-dev local ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/upsmon-usb/EXT/DownOS /opt/upsmon-usb/EXT/JSystem /service /usr/inferno/keydb /usr/inferno/lib /usr/inferno/services /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /var/log /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage-distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y" FCFLAGS="-march=native -O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr" FFLAGS="-march=native -O2 -pipe" GENTOO_MIRRORS="http://gentoo.kiev.ua/ftp/ http://mirror.yandex.ru/gentoo-distfiles/ http://gentoo.iteam.net.ua/" LANG="ru_RU.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j8" PKGDIR="/usr/portage-packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded" 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/powerman /var/lib/layman/perl-experimental-snapshots /var/lib/layman/gamerlay /var/lib/layman/hardened-development /usr/local/portage" SYNC="rsync://rsync.ua.gentoo.org/gentoo-portage" USE="X a52 aac acl alac alsa amd64 avx bash-completion berkdb bzip2 caps cdda cddb cli cracklib crypt cxx dbus dri dts dvb dvd flac fontconfig gdbm gif gnutls gpg gpm hardened iconv icu id3tag idn ipv6 jpeg jpeg2k justify libnotify mac mad matroska mbox mmx mng modules mp3 mpeg mudflap multilib musepack mysql ncurses network-cron nls nptl nsplugin ogg opengl openmp pam pax_kernel pcre perl png qt3support readline session spell sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 svg tcpd theora tiff truetype unicode urandom vdpau vim-syntax vorbis wavpack x264 xattr xosd xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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="log_config vhost_alias autoindex alias rewrite dir deflate filter mime negotiation auth_basic authn_file authz_host authz_user authz_groupfile cgi actions headers env setenvif" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" 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 ru" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="x86_64 i386" QEMU_USER_TARGETS="x86_64 i386" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nvidia nv nouveau" 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, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON ================================================================= Package Settings ================================================================= sys-apps/elfix-0.8.1 was built with the following: USE="ptpax xtpax"
(In reply to comment #6) > for both xorg and skype i'd like to see the PaX status on /proc/pid/status, In short: 1) According to /proc/$(pidof Xorg)/status, on XATTR_PAX only kernel MPROTECT doesn't disabled by unknown reason, while on XATTR_PAX+PT_PAX and PT_PAX only kernels it's disabled. 2) `emerge skype` on XATTR_PAX+PT_PAX and PT_PAX only kernels using eclass from hardened-development overlay result in broken skype. Looks like two different unrelated bugs, one in PaX and another in eclass. I'll post long story in next comment.
Long story. 1) Before migration (everything works): home ~ # uname -a Linux home 3.8.4-hardened #8 SMP PREEMPT Tue Mar 26 02:13:05 EET 2013 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux home ~ # zgrep XATTR= /proc/config.gz CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS_XATTR=y CONFIG_REISERFS_FS_XATTR=y CONFIG_TMPFS_XATTR=y CONFIG_SQUASHFS_XATTR=y CONFIG_CIFS_XATTR=y home ~ # zgrep PAX_FLAGS /proc/config.gz CONFIG_PAX_PT_PAX_FLAGS=y # CONFIG_PAX_XATTR_PAX_FLAGS is not set home ~ # layman -l | grep hardened * hardened-development [Git ] (git://git.o.g.o/proj/hardened-dev...) home ~ # cat /etc/portage/repos.conf # [DEFAULT] # eclass-overrides = hardened-dev home ~ # emerge -pv elfix coreutils | grep ebuild [ebuild R ] sys-apps/elfix-0.8.1 USE="ptpax xtpax" 0 kB [ebuild R ] sys-apps/coreutils-8.20 USE="acl caps nls xattr -gmp (-selinux) -static -vanilla" 0 kB home ~ # paxctl-ng -v /usr/bin/Xorg /usr/bin/Xorg: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: not found home ~ # paxctl-ng -v /opt/bin/skype /opt/bin/skype: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: not found home ~ # getfattr -d /usr/bin/Xorg home ~ # getfattr -d /opt/bin/skype home ~ # grep PaX /proc/$(pidof X)/status PaX: PemRs home ~ # grep PaX /proc/$(pidof skype)/status PaX: PemRs 2) Migration: home ~ # cat /etc/portage/repos.conf [DEFAULT] eclass-overrides = hardened-dev home ~ # migrate-pax -m home ~ # paxctl-ng -v /usr/bin/Xorg /usr/bin/Xorg: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: -em-- home ~ # paxctl-ng -v /opt/bin/skype /opt/bin/skype: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: -em-- home ~ # getfattr -d /usr/bin/Xorg getfattr: Removing leading '/' from absolute path names # file: usr/bin/Xorg user.pax.flags="em" home ~ # getfattr -d /opt/bin/skype getfattr: Removing leading '/' from absolute path names # file: opt/bin/skype user.pax.flags="em" 3) Boot into an XATTR_PAX only kernel (Xorg fail to load GLX module, skype works): home ~ # uname -a Linux home 3.8.4-hardened_xattr #10 SMP PREEMPT Tue Mar 26 02:19:32 EET 2013 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux home ~ # zgrep XATTR= /proc/config.gz CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS_XATTR=y CONFIG_REISERFS_FS_XATTR=y CONFIG_TMPFS_XATTR=y CONFIG_SQUASHFS_XATTR=y CONFIG_CIFS_XATTR=y home ~ # zgrep PAX_FLAGS /proc/config.gz # CONFIG_PAX_PT_PAX_FLAGS is not set CONFIG_PAX_XATTR_PAX_FLAGS=y home ~ # paxctl-ng -v /usr/bin/Xorg /usr/bin/Xorg: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: -em-- home ~ # paxctl-ng -v /opt/bin/skype /opt/bin/skype: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: -em-- home ~ # getfattr -d /usr/bin/Xorg getfattr: Removing leading '/' from absolute path names # file: usr/bin/Xorg user.pax.flags="em" home ~ # getfattr -d /opt/bin/skype getfattr: Removing leading '/' from absolute path names # file: opt/bin/skype user.pax.flags="em" home ~ # grep PaX /proc/$(pidof X)/status PaX: PeMRs home ~ # grep PaX /proc/$(pidof skype)/status PaX: PemRs 4) Boot into an PT_PAX + XATTR_PAX only kernel (Xorg load GLX module, skype works): home ~ # uname -a Linux home 3.8.4-hardened_pt_xattr #9 SMP PREEMPT Tue Mar 26 02:17:51 EET 2013 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux home ~ # zgrep XATTR= /proc/config.gz CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS_XATTR=y CONFIG_REISERFS_FS_XATTR=y CONFIG_TMPFS_XATTR=y CONFIG_SQUASHFS_XATTR=y CONFIG_CIFS_XATTR=y home ~ # zgrep PAX_FLAGS /proc/config.gz CONFIG_PAX_PT_PAX_FLAGS=y CONFIG_PAX_XATTR_PAX_FLAGS=y home ~ # paxctl-ng -v /usr/bin/Xorg /usr/bin/Xorg: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: -em-- home ~ # paxctl-ng -v /opt/bin/skype /opt/bin/skype: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: -em-- home ~ # getfattr -d /usr/bin/Xorg getfattr: Removing leading '/' from absolute path names # file: usr/bin/Xorg user.pax.flags="em" home ~ # getfattr -d /opt/bin/skype getfattr: Removing leading '/' from absolute path names # file: opt/bin/skype user.pax.flags="em" home ~ # grep PaX /proc/$(pidof X)/status PaX: PemRs home ~ # grep PaX /proc/$(pidof skype)/status PaX: PemRs 5) Boot into an XATTR_PAX only kernel (again): home ~ # emerge -av skype ... [ebuild R #] net-im/skype-4.1.0.20 USE="pax_kernel (-selinux)" 0 kB ... home ~ # paxctl-ng -v /opt/bin/skype /opt/bin/skype: PT_PAX : -em-- XATTR_PAX: -em-- home ~ # getfattr -d /opt/bin/skype getfattr: Removing leading '/' from absolute path names # file: opt/bin/skype user.pax.flags="em" Now I'm quit from skype and trying to start it again: powerman@home ~ $ skype Fatal: QWidget: Must construct a QApplication before a QPaintDevice Aborted Next I've boot into an PT_PAX+XATTR_PAX kernel, emerge skype - same thing, it doesn't work. Next I've boot into an PT_PAX kernel, skype still doesn't work, emerge skype failed: * PT PaX marking -m with paxctl * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * XT PaX marking -m with paxctl-ng * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * Failed to set XT_PAX markings -m for: * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * Executables may be killed by PaX kernels. * ERROR: net-im/skype-4.1.0.20 failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 2469: Called die * The specific snippet of code: * pax-mark Cm "${ED}"/opt/bin/${PN} || die; Then I disable repos.conf, emerge skype - and it works now: home ~ # cat /etc/portage/repos.conf # [DEFAULT] # eclass-overrides = hardened-dev home ~ # paxctl-ng -v /opt/bin/skype /opt/bin/skype: PT_PAX : -em-- XATTR_PAX: -em-- home ~ # getfattr -d /opt/bin/skype getfattr: Removing leading '/' from absolute path names # file: opt/bin/skype user.pax.flags="em" home ~ # emerge skype home ~ # paxctl-ng -v /opt/bin/skype /opt/bin/skype: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -em-- XATTR_PAX: not found home ~ # getfattr -d /opt/bin/skype
(In reply to comment #11) > 2) `emerge skype` on XATTR_PAX+PT_PAX and PT_PAX only kernels using eclass This should be "on XATTR_PAX+PT_PAX and XATTR_PAX only kernels" instead.
(In reply to comment #12) > Long story. One issue at a time. I want to make sure the eclass is right because I plan to put it on the tree tomorrow. > 5) Boot into an XATTR_PAX only kernel (again): > > home ~ # emerge -av skype > ... > [ebuild R #] net-im/skype-4.1.0.20 USE="pax_kernel (-selinux)" 0 kB > ... > > home ~ # paxctl-ng -v /opt/bin/skype > /opt/bin/skype: > PT_PAX : -em-- > XATTR_PAX: -em-- > > home ~ # getfattr -d /opt/bin/skype > getfattr: Removing leading '/' from absolute path names > # file: opt/bin/skype > user.pax.flags="em" > > Now I'm quit from skype and trying to start it again: Are you saying that you had skype running under a XATTR_PAX only kernel with the above flags. Then you quit, and on *restarting* it you get the next error? > powerman@home ~ $ skype > Fatal: QWidget: Must construct a QApplication before a QPaintDevice > Aborted The following appears to be a behavior of an older version of the eclass. Can you confirm you're using the latest? > Next I've boot into an PT_PAX+XATTR_PAX kernel, emerge skype - > same thing, it doesn't work. > > Next I've boot into an PT_PAX kernel, skype still doesn't work, > emerge skype failed: > > * PT PaX marking -m with paxctl > * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype > * XT PaX marking -m with paxctl-ng > * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype > * Failed to set XT_PAX markings -m for: > * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype > * Executables may be killed by PaX kernels. > * ERROR: net-im/skype-4.1.0.20 failed (install phase): > * (no error message) > * > * Call stack: > * ebuild.sh, line 93: Called src_install > * environment, line 2469: Called die > * The specific snippet of code: > * pax-mark Cm "${ED}"/opt/bin/${PN} || die; > > Then I disable repos.conf, emerge skype - and it works now: > > home ~ # cat /etc/portage/repos.conf > # [DEFAULT] > # eclass-overrides = hardened-dev > > home ~ # paxctl-ng -v /opt/bin/skype > /opt/bin/skype: > PT_PAX : -em-- > XATTR_PAX: -em-- > > home ~ # getfattr -d /opt/bin/skype > getfattr: Removing leading '/' from absolute path names > # file: opt/bin/skype > user.pax.flags="em" > > home ~ # emerge skype > > home ~ # paxctl-ng -v /opt/bin/skype > /opt/bin/skype: > open(O_RDWR) failed: cannot change PT_PAX flags > PT_PAX : -em-- > XATTR_PAX: not found > > home ~ # getfattr -d /opt/bin/skype
(In reply to comment #14) > (In reply to comment #12) > > Are you saying that you had skype running under a XATTR_PAX only kernel with > the above flags. Then you quit, and on *restarting* it you get the next > error? > > > powerman@home ~ $ skype > > Fatal: QWidget: Must construct a QApplication before a QPaintDevice > > Aborted > Okay skype breaks if you try to convert it GNU_STACK to PT_PAX. Why, I have no idea. The pax kernel doesn't use the GNU_STACK but the elf is fragile enough that it breaks. Set PAX_MARKINGS="XT" in your /etc/portage/make.conf and *only* set XATTR_PAX flags from now on. See if this doesn't fix your other issues too.
(In reply to comment #15) > Okay skype breaks if you try to convert it GNU_STACK to PT_PAX. Why, I have > no idea. i guess there's still some amount of self-checking left in there then ;).
(In reply to comment #15) > Set PAX_MARKINGS="XT" in your /etc/portage/make.conf and *only* set > XATTR_PAX flags from now on. See if this doesn't fix your other issues too. Yeah, it helps with skype. But it doesn't (and can't) help with Xorg. > Okay skype breaks if you try to convert it GNU_STACK to PT_PAX. Why, I have > no idea. The pax kernel doesn't use the GNU_STACK but the elf is fragile > enough that it breaks. Thing is, skype always breaks after `paxctl -c`, but works ok with `paxctl -C`. So, problem is in these lines hardened-development/eclass/pax-utils.eclass:82 # First, try modifying the existing PAX_FLAGS header paxctl -q${flags} "${f}" && continue # Second, try stealing the (unused under PaX) PT_GNU_STACK header paxctl -qc${flags} "${f}" && continue # Third, creating a PT_PAX header (works on ET_EXEC) paxctl -qC${flags} "${f}" && continue I think if you try -C first and -c next it should fix issue with skype and probably shouldn't break anything else. Another option is doesn't ignore pax-mark "C" option (used in skype ebuild) and when it's used don't try to do -c/-C guessing, just do -C.
(In reply to comment #17) > I think if you try -C first and -c next it should fix issue with skype and > probably shouldn't break anything else. -c is preferred to -C because the latter does some major surgery on the binary, it's best used for really special cases like skype (and i have memories that skype would d detect even that and this was in fact one of the motivating factors in the xattr based flags development). > Another option is doesn't ignore > pax-mark "C" option (used in skype ebuild) and when it's used don't try to > do -c/-C guessing, just do -C. yes, that sounds better.
Okay I made some improvements to the eclass. I'm holding off for some last minute testing. Let me know if this works better for you.
(In reply to comment #19) > Okay I made some improvements to the eclass. I'm holding off for some last > minute testing. Let me know if this works better for you. First issue with eclass won't fixed yet - `emerge skype` still fails on PT_PAX only kernel: >>> Install skype-4.1.0.20 into /var/tmp/portage/net-im/skype-4.1.0.20/image/ category net-im * PT PaX marking -m with paxctl * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * XT PaX marking -m with paxctl-ng * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * Failed to set XT_PAX markings -m for: * /var/tmp/portage/net-im/skype-4.1.0.20/image//opt/bin/skype * Executables may be killed by PaX kernels. * ERROR: net-im/skype-4.1.0.20 failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 2469: Called die * The specific snippet of code: * pax-mark Cm "${ED}"/opt/bin/${PN} || die; I'm now going to boot XATTR_PAX only kernel to see is second issue solved (is `emerge skype` will result in working skype binary). BTW, you probably also wanna update comment at pax-utils.eclass:67 to list modified order of -C -c options.
(In reply to comment #20) > I'm now going to boot XATTR_PAX only kernel to see is second issue solved > (is `emerge skype` will result in working skype binary). Yes, this is fixed now, skype works. @pageexec: what's about non-disabled MPROTECT on -m paxmarked Xorg on XATTR_PAX-enabled kernel? do you plan to fix this and is I can help?
Xorg XATTR/MPROTECT still broken in 3.8.7.
(In reply to comment #22) > Xorg XATTR/MPROTECT still broken in 3.8.7. i tried to reproduce it with a suid cat but it worked fine for me. can you also do this test: 1. make a suid copy of cat, 2. cat /proc/self/status.
(In reply to comment #23) > i tried to reproduce it with a suid cat but it worked fine for me. can you > also do this test: 1. make a suid copy of cat, 2. cat /proc/self/status. suid cat works because it's not enough to chmod +s, cat should call some syscall to switch uid, but it doesn't call it. But look like your idea about suid is correct. I've experimented with suid `/tmp/sleep 60` and suid `/tmp/sudo sleep 60` - sleep got correct paxmarking in /proc/$(pidof sleep)/status, while sudo doesn't - just like Xorg.
(In reply to comment #24) > suid cat works because it's not enough to chmod +s, cat should call some > syscall to switch uid, but it doesn't call it. hmm, this makes no sense, the PaX flags are determined at execve, not any time later. however it can mean only one thing: vfs_getxattr fails to read the xattrs and the default PaX flags got applied. this can happen for example if your user doesn't have read access to the given file, which is probably the case for most suid apps. i'm afraid this is a limitation i cannot fix without disabling all security checks in this function.
one workaround could be to create an alternative to vfs_getxattr that'd check for MAY_EXEC instead of MAY_READ (technically this is what open_exec checks anyway, so it's not like we'd open up holes). i'll think about it.
Btw, what's wrong with reading suid apps, in general? I can imagine suid app which contain some password in it code, so user can run it (and it will then decide allow that user to do what he want using that password or not) but can't disassemble or `strings` it and get password. But to be honest I'm not aware about such suid binaries on general Linux installation at all. Neither sudo nor Xorg doesn't contain any sensitive information inside, so why not just make Xorg's binary readable by all? Or this will break some internal suid-related checks in kernel and it won't work as suid in this case?
(In reply to comment #27) > Btw, what's wrong with reading suid apps, in general? > > I can imagine suid app which contain some password in it code, so user can > run it (and it will then decide allow that user to do what he want using > that password or not) but can't disassemble or `strings` it and get password. > > But to be honest I'm not aware about such suid binaries on general Linux > installation at all. Neither sudo nor Xorg doesn't contain any sensitive > information inside, so why not just make Xorg's binary readable by all? Or > this will break some internal suid-related checks in kernel and it won't > work as suid in this case? Because these apps could be abused for privilege escalation, and having the suid binary readable gives a lot of information to potential attackers, starting from knowing application offsets to abuse, symbol placement and more. Disabling the read permission ensures this can't be done on systems like Gentoo where the attacker has no way of getting the information (since it depends on compiler used, compiler flags, use flags etc).
(In reply to comment #28) > Disabling the read permission ensures this can't be done on systems like > Gentoo where the attacker has no way of getting the information (since it > depends on compiler used, compiler flags, use flags etc). Thanks, I see. But, to be honest, all this information (compiler, use flags, etc.) is perfectly readable for anyone by default, so it's not a big deal to build same binary on another system (I'm not sure, but I suppose it may be even possible to build same binary on SAME system by using some FEATURES/emerge options to force emerge to work in subdir/chroot without root privileges). It's good most Gentoo installations have different binaries, it makes harder to own them all using single worm, but I don't think we can protect against exploiting known hole in that one given binary of open source app by just making it non-readable and hoping our compilation kung-fu is unique and can't be easily repeated.
(In reply to comment #29) > (In reply to comment #28) > > Disabling the read permission ensures this can't be done on systems like > > Gentoo where the attacker has no way of getting the information (since it > > depends on compiler used, compiler flags, use flags etc). > > Thanks, I see. But, to be honest, all this information (compiler, use flags, > etc.) is perfectly readable for anyone by default, so it's not a big deal to > build same binary on another system (I'm not sure, but I suppose it may be > even possible to build same binary on SAME system by using some > FEATURES/emerge options to force emerge to work in subdir/chroot without > root privileges). Well you still will need the same compiler which may not be already on the system and even with all that the same compiler may result in different binaries. And I think you can keep the portage info in /etc/portage hidden from users not in the portage group if desired (although I'm not that sure) > It's good most Gentoo installations have different binaries, it makes harder > to own them all using single worm, but I don't think we can protect against > exploiting known hole in that one given binary of open source app by just > making it non-readable and hoping our compilation kung-fu is unique and > can't be easily repeated. I recall this has worked before (at least making the system harder to exploit), so it will likely work again :P
the latest patch should fix this. as for suid apps being unreadable, it's cargo cult security if at least ptrace isn't disallowed on them which is what grsec can do but probably nobody else does. also i think reproducing the same binary isn't rocket science, the parameter space (exact toolchain/app versions and their configs mostly) isn't that big.
