Summary: | sys-apps/chpax: breaks elf binaries | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anthony Basile <blueness> |
Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | pageexec, spender |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 427888 |
Description
Anthony Basile
2011-10-17 20:13:57 UTC
(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. |