| Summary: | pax-utils.eclass attempts to set PaX markings on non-hardened profile | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Roman Žilka <roman.zilka> |
| Component: | Core | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | chithanh |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 427888, 465070 | ||
| Attachments: | emerge --info | ||
|
Description
Roman Žilka
2013-04-07 09:39:07 UTC
Created attachment 344698 [details]
emerge --info
(In reply to comment #1) > Created attachment 344698 [details] > emerge --info This is correct behavior because whether or not you use the hardened profile, you can still use a pax hardened kernel. In that case you will need the pax markings even with a non-hardened profile This would only be a bug if it broke something. So I'll leave the bug open for more discussion, but I'm inclined to close it invalid. (In reply to comment #2) > This is correct behavior because whether or not you use the hardened > profile, you can still use a pax hardened kernel. In that case you will > need the pax markings even with a non-hardened profile Non-hardened profiles never called pax before the recent xattr-related change IIRC. According to what you're saying there might be a bug in the non-hardened profiles that's been there ever since pax-awareness made it into Gentoo. Also consider the fact that on my non-hardened machine there seems to be no means of setting xattrs - I have neither pypax.so, nor pyxattr, nor setfattr, nor elfix (paxctl-ng). I.e., there is nothing that pulls any of that into the system (on my hardened box it seems to be portage[xattr], which is now enforced). Either that's a bug, or somebody didn't plan on setting pax stuff on non-hardened, it seems. (In reply to comment #0) > I use the default/linux/x86/13.0 profile, but emerge attempts to set xattr > PaX bits after compilation. See warnings for python-3.2.3-r2, > spidermonkey-1.8.5-r4, python-2.7.3-r3, grub-0.97-r12, ... Portage doesn't do anything with xattrs unless you have FEATURES=xattr enabled, and I don't see it enabled in your emerge --info. So, I suspect that this bug is assigned to the wrong team. Maybe you need to file separate bugs for each of those packages. (In reply to comment #4) > (In reply to comment #0) > > I use the default/linux/x86/13.0 profile, but emerge attempts to set xattr > > PaX bits after compilation. See warnings for python-3.2.3-r2, > > spidermonkey-1.8.5-r4, python-2.7.3-r3, grub-0.97-r12, ... > > Portage doesn't do anything with xattrs unless you have FEATURES=xattr > enabled, and I don't see it enabled in your emerge --info. So, I suspect > that this bug is assigned to the wrong team. Maybe you need to file separate > bugs for each of those packages. Well, there would be many. Shouldn't pax-utils.eclass check for the FEATURE (=> centralized, easily maintained)? If not, I might open the pkg-specific bugs, but as I'm grepping the tree, it looks like I might as well open a tracker, because no ebuild seems to check for the FEATURE. In either case, please consider documenting this purpose of the "xattr" FEATURE in make.conf(5). There also may be some overlaps to consider in the role of the "xattr" USE flag in sys-apps/portage and the "xattr" FEATURE. The previous issues of this bug# are still open, though. (In reply to comment #5) > Well, there would be many. Shouldn't pax-utils.eclass check for the FEATURE > (=> centralized, easily maintained)? If not, I might open the pkg-specific > bugs, but as I'm grepping the tree, it looks like I might as well open a > tracker, because no ebuild seems to check for the FEATURE. Well, pax-utils.eclass is not part of sys-apps/portage, so I'm reassigning this bug to hardened@gentoo.org. > In either case, please consider documenting this purpose of the "xattr" > FEATURE in make.conf(5). There also may be some overlaps to consider in the > role of the "xattr" USE flag in sys-apps/portage and the "xattr" FEATURE. Please file new bugs for any issues that are directly related to xattr support in sys-apps/portage. (In reply to comment #3) > (In reply to comment #2) > > This is correct behavior because whether or not you use the hardened > > profile, you can still use a pax hardened kernel. In that case you will > > need the pax markings even with a non-hardened profile > > Non-hardened profiles never called pax before the recent xattr-related > change IIRC. No, non-hardened profiles have always had pax markings, you just didn't know about it and didn't care since non-pax kernels just ignore the phdr. Try readelf -l /bin/bash | grep -C 3 PAX_FLAGS I think the solutuion here is to check for both PAX_MARKINGS="XT" and USE="xattr". If I give you a patch to try will you tell me if it fixes your problem. (In reply to comment #7) > No, non-hardened profiles have always had pax markings, you just didn't know > about it and didn't care since non-pax kernels just ignore the phdr. Try > > readelf -l /bin/bash | grep -C 3 PAX_FLAGS You're right, sorry. I wonder how I never noticed in the compile printouts. By the way, the bash ebuild doesn't apply any marks - FYI in case it's a problem. I re-tried with dev-lang/spidermonkey-1.8.5-r4 which (on non-hardened) says: * Fallback PaX marking -m with scanelf * /boot/tmp/portage/dev-lang/spidermonkey-1.8.5-r4/image//usr/bin/js TYPE PAX FILE ET_EXEC --mxe- /boot/tmp/portage/dev-lang/spidermonkey-1.8.5-r4/image//usr/bin/js * Failed to set XATTR_PAX markings -m for: * /boot/tmp/portage/dev-lang/spidermonkey-1.8.5-r4/image//usr/bin/js * Executables may be killed by PaX kernels. # readelf -l /usr/bin/js | grep PAX_FLAGS PAX_FLAGS 0x000000 0x00000000 0x00000000 0x00000 0x00000 0x4 It looks like there are no flags set in the actual file, though. I get the same result with spidermonkey on hardened (which calls paxctl and paxctl-ng). > I think the solutuion here is to check for both PAX_MARKINGS="XT" and > USE="xattr". If I give you a patch to try will you tell me if it fixes your > problem. I'm not following you here, but I'll test any patches you want. > > I think the solutuion here is to check for both PAX_MARKINGS="XT" and
> > USE="xattr". If I give you a patch to try will you tell me if it fixes your
> > problem.
>
> I'm not following you here, but I'll test any patches you want.
In the eclass we currently only check if PAX_MARKINGS="XT" before trying to XATTR_PAX mark. We do not check if use xattr is set. The reason I didn't is because you don't need it set for all packages to make XATTR_PAX markings work.
I'm still thinking about the best way to approach this.
My suggestion would be addition of FEATURES="pax"(?) which triggers a new ebuild phase, similar to FEATURES="test" today. Alternatively, pax-mark may have to be made conditional on USE="pax-kernel" (that flag could come from the eclass) or similar, so not everybody must install tools for that. By the way, it looks like certain (all?) packages apply the marks while the files are still in TMPDIR. That's a problem if TMPDIR doesn't support xattr (while the target fs does). Is that enough of a reason to file per-package bugs about this? (In reply to comment #11) > By the way, it looks like certain (all?) packages apply the marks while the > files are still in TMPDIR. That's a problem if TMPDIR doesn't support xattr > (while the target fs does). Is that enough of a reason to file per-package > bugs about this? Its not a problem if it fails unless there is an || die in the ebuild. So if we remove that from packages that have it, we just get an annoying warning, which we have just dropped to elog. So per package might work here. Okay the original issue "pax-utils.eclass attempts to set PaX markings on non-hardened profile" is not really valid as argued in comment 7. This doesn't mean there aren't *other* issues. I'm closing this and we can continue discussion in other bug reports. (In reply to comment #13) > Okay the original issue "pax-utils.eclass attempts to set PaX markings on > non-hardened profile" is not really valid as argued in comment 7. Yes, it's invalid. But since there's another open issue that we've started discussing here, I suggest renaming and reopening this bug# for that purpose. (I mean the thing about making the eclass honor FEATURES="xattr".) By the way, note that according to Zac Medico in #c4, the eclass should honor not (only) the USE flag xattr, but the FEATURE xattr. That's why I suggested that the semantics of the USE flag and the FEATURE be revised to remove any possible overlaps/confusions of meaning. (In reply to comment #15) > By the way, note that according to Zac Medico in #c4, the eclass should > honor not (only) the USE flag xattr, but the FEATURE xattr. He did not say that. (In reply to comment #16) > (In reply to comment #15) > > By the way, note that according to Zac Medico in #c4, the eclass should > > honor not (only) the USE flag xattr, but the FEATURE xattr. > > He did not say that. Based on what he was replying to I just can't imagine he hadn't said and meant exactly that. But I'm leaving this topic be, then. |
