While working on integrating chpax functionality into paxctl-ng in sys-apps/elfix, I found the following: yellowness paxmark-libs # ldd /bin/ls linux-vdso.so.1 => (0x00007fffc25ff000) librt.so.1 => /lib64/librt.so.1 (0x00007f9cf387b000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f9cf3675000) libacl.so.1 => /lib64/libacl.so.1 (0x00007f9cf346b000) libc.so.6 => /lib64/libc.so.6 (0x00007f9cf30ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9cf2ee2000) /lib64/ld-linux-x86-64.so.2 (0x00007f9cf3a84000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f9cf2cdc000) yellowness paxmark-libs # chpax -m /bin/ls yellowness paxmark-libs # ldd /bin/ls not a dynamic executable yellowness paxmark-libs # chpax -M /bin/ls yellowness paxmark-libs # ldd /bin/ls linux-vdso.so.1 => (0x00007fff7e729000) librt.so.1 => /lib64/librt.so.1 (0x00007f0cdc19b000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f0cdbf95000) libacl.so.1 => /lib64/libacl.so.1 (0x00007f0cdbd8b000) libc.so.6 => /lib64/libc.so.6 (0x00007f0cdba1f000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0cdb802000) /lib64/ld-linux-x86-64.so.2 (0x00007f0cdc3a4000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f0cdb5fc000) So setting -m and then removing it confuses ldd. Similarly: -E breaks it and -e fixes it -r breaks it and -R fixes it -X breaks it and -x fixes it However! -p breaks it, but -P does NOT fix it -s breaks it, but -S does NOT fix it Looks like something is looking at bytes 14 and 15 ehdr.e_ident[].
(In reply to comment #0) > So setting -m and then removing it confuses ldd. Similarly: I did not say that right: so setting -m confuses ldd while removing it fixes it.
it's glibc commit 04f2902d9fadb2b8221162247412fb2c4667d95e from Mar 18 2010 so i guess not many people are using chpax anymore if it took this long to run across this problem ;). as i always said, chpax must die so it's either a WONTFIX or revert that glibc commit...
(In reply to comment #2) > it's glibc commit 04f2902d9fadb2b8221162247412fb2c4667d95e from Mar 18 2010 so > i guess not many people are using chpax anymore if it took this long to run > across this problem ;). as i always said, chpax must die so it's either a > WONTFIX or revert that glibc commit... Agreed. Shouldn't we then remove CONFIG_PAX_EI_PAX. I wrote a patch to do just that. I guess then for binaries where we cannot add a PT_PAX phdr, we should just default to the most secure settings.
(In reply to comment #3) > Agreed. Shouldn't we then remove CONFIG_PAX_EI_PAX. I wrote a patch to do > just that. > > I guess then for binaries where we cannot add a PT_PAX phdr, we should just > default to the most secure settings. i'd rather remove EI_PAX only when the extended attr method is done (but in gentoo you can do it earlier if you want to).
(In reply to comment #4) > (In reply to comment #3) > > Agreed. Shouldn't we then remove CONFIG_PAX_EI_PAX. I wrote a patch to do > > just that. > > > > I guess then for binaries where we cannot add a PT_PAX phdr, we should just > > default to the most secure settings. > > i'd rather remove EI_PAX only when the extended attr method is done (but in > gentoo you can do it earlier if you want to). Okay, let's go with that plan. I've played with some name spaces. I was going to add pax.* but after some playing around, I see no reason not to use "trusted.pax" for the flags. This can only be set by someone with CAP_SYS_ADMIN which is pretty much what setting PT_PAX requires. I've got the userland down, now I have to get the kernel code done.
(In reply to comment #5) > I've played with some name spaces. I was going to add pax.* but after some > playing around, I see no reason not to use "trusted.pax" for the flags. This > can only be set by someone with CAP_SYS_ADMIN which is pretty much what setting > PT_PAX requires. not exactly, PT_PAX_FLAGS can be set by the owner, it doesn't need any capability per se (think about a user compiling/installing a binary for his own and wanting to set some PaX flags on it explicitly). so i think that pretty much leaves the user namespace.
Its off the tree.
