| Summary: | pax-utils.eclass: warn if there is no xattr-setting tool and yet PAX_MARKINGS="XT" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Roman Žilka <roman.zilka> |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nikoli |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 464932 | ||
| Bug Blocks: | 427888 | ||
| Attachments: | emerge --info | ||
|
Description
Roman Žilka
2013-04-08 11:19:34 UTC
Created attachment 344816 [details]
emerge --info
(In reply to comment #0) > pax-utils.eclass recently switched to setting xattr PaX marks, yet on my > non-hardened system there is no tool that can set xattrs. I think @system or > sys-apps/portage or something should pull in a tool which can set xattrs if > xattr PaX marks are to be set on a system-wide scale such as by means of > pax-utils.eclass. > > Tested with 'strace -f -e execve emerge grub' - only scanelf is called to > set elf marks. The system has none of elfix, paxctl, pyxattr, setfattr. > > Reproducible: Always See my comenet at https://bugs.gentoo.org/show_bug.cgi?id=464932#c12. I'm not sure I understand. If there is not an '|| die' in the ebuild, only a warning will be produced and no action. But the purpose of the recent xattr-PaX marking switch is to set PaX marks, right? You (developers) decided it's desirable for people to have these marks present. Why don't you make sure that your eclass not only attempts to do that, but also has an actual tool to do so? You're leaving it up to the user to install a xattr-setter by hand, and the eclass doesn't even give a hint as to why the xattr set attempt failed and what needs to be done (no xattr support in fs / no xattr setter / other error). As of now, the eclass doesn't respond to FEATURES="xattr". But when bug 464932 is fixed and it does respond to it, isn't it logical to pull in a xattr-setter, when the user explicitly requested xattr marking by having FEATURES="xattr"? (In reply to comment #3) > I'm not sure I understand. If there is not an '|| die' in the ebuild, only a > warning will be produced and no action. But the purpose of the recent > xattr-PaX marking switch is to set PaX marks, right? You (developers) > decided it's desirable for people to have these marks present. Why don't you > make sure that your eclass not only attempts to do that, but also has an > actual tool to do so? You're leaving it up to the user to install a > xattr-setter by hand, and the eclass doesn't even give a hint as to why the > xattr set attempt failed and what needs to be done (no xattr support in fs / > no xattr setter / other error). > > As of now, the eclass doesn't respond to FEATURES="xattr". But when bug > 464932 is fixed and it does respond to it, isn't it logical to pull in a > xattr-setter, when the user explicitly requested xattr marking by having > FEATURES="xattr"? On any hardened profile, the appropriate tools will be there because we pull in paxctl and paxctl-ng and we force USE=xattr globally. On a non-hardened profile, the failure is okay in that you don't need the markings (unless it causes the ebuild to fail which needs to be fixed). Furthermore, using a pax hardened kernel, you will always get xattr support on your filesystems. The only thing I'm working through is users who switch back and forth between the profiles and/or the kernels. Then the xattr pax markings can get lost and we don't want users to have to recompile a whole package just to get the markings back. (In reply to comment #4) > On any hardened profile, the appropriate tools will be there because we pull > in paxctl and paxctl-ng and we force USE=xattr globally. On a non-hardened > profile, the failure is okay in that you don't need the markings (unless it > causes the ebuild to fail which needs to be fixed). I'm confused. In 464932#c2 you said that non-hardened people need PaX markings just as much as hardened people do. Actually, that's the reason why you'd closed bug 464932 with its original purpose ("pax-utils.eclass attempts to set PaX markings on non-hardened profile"), if I'm getting things. By the way, on hardened USE=xattr is not forced globally - it's forced for the portage ebuild only. I don't know if that's a problem (not as far as I can tell) - just FYI. > Furthermore, using a pax hardened kernel, you will always get xattr support > on your filesystems. I have pax-enabled hardened-sources on another machine (hardened profile), but the kernel doesn't enforce xattr support for no FS I use. All ebuilds fail to set xattrs, although paxctl-ng is available. # grep -i xattr /boot/config # CONFIG_EXT4_FS_XATTR is not set # CONFIG_TMPFS_XATTR is not set # CONFIG_PAX_XATTR_PAX_FLAGS is not set > The only thing I'm working through is users who switch back and forth > between the profiles and/or the kernels. Then the xattr pax markings can > get lost and we don't want users to have to recompile a whole package just > to get the markings back. Again, this seems contradictory to 464932#c2. Same story as above in this comment. (In reply to comment #5) > (In reply to comment #4) > > On any hardened profile, the appropriate tools will be there because we pull > > in paxctl and paxctl-ng and we force USE=xattr globally. On a non-hardened > > profile, the failure is okay in that you don't need the markings (unless it > > causes the ebuild to fail which needs to be fixed). > > I'm confused. In 464932#c2 you said that non-hardened people need PaX > markings just as much as hardened people do. Actually, that's the reason why > you'd closed bug 464932 with its original purpose ("pax-utils.eclass > attempts to set PaX markings on non-hardened profile"), if I'm getting > things. No, non-hardened profiles don't *need* PaX markings, but they could use pax markings if they switched in the future. This would save the problem of redoing the markings. I closed the bug because "pax-utils.eclass attempts to set PaX markings on non-hardened profile" is the correct behavior. > > By the way, on hardened USE=xattr is not forced globally - it's forced for > the portage ebuild only. I don't know if that's a problem (not as far as I > can tell) - just FYI. Yeah, in tests I determined this was enough but maybe it isn't for coreutils. During the upcoming meeting we'll discuss turning it on globally. > > > Furthermore, using a pax hardened kernel, you will always get xattr support > > on your filesystems. > > I have pax-enabled hardened-sources on another machine (hardened profile), > but the kernel doesn't enforce xattr support for no FS I use. All ebuilds > fail to set xattrs, although paxctl-ng is available. > > # grep -i xattr /boot/config > # CONFIG_EXT4_FS_XATTR is not set > # CONFIG_TMPFS_XATTR is not set > # CONFIG_PAX_XATTR_PAX_FLAGS is not set > > > The only thing I'm working through is users who switch back and forth > > between the profiles and/or the kernels. Then the xattr pax markings can > > get lost and we don't want users to have to recompile a whole package just > > to get the markings back. > > Again, this seems contradictory to 464932#c2. Same story as above in this > comment. Sorry pax hardened kernel with CONFIG_PAX_XATTR_PAX_FLAGS=y. (In reply to comment #6) > (In reply to comment #5) > > I'm confused. In 464932#c2 you said that non-hardened people need PaX > > markings just as much as hardened people do. Actually, that's the reason why > > you'd closed bug 464932 with its original purpose ("pax-utils.eclass > > attempts to set PaX markings on non-hardened profile"), if I'm getting > > things. > > No, non-hardened profiles don't *need* PaX markings, but they could use pax > markings if they switched in the future. This would save the problem of > redoing the markings. OK, non-h profiles don't need the markings at the moment, but you want those profiles to have the markings anyway. That's why you made the eclass such that it sets the xattrs even on non-h. You intend for the non-h people to have the markings, you instruct the eclass to call the appropriate commands, but you don't pull those commands' binaries into the system. That way, all your efforts and intentions for the markings are in vain, because the actual xatrr-setters are a bottleneck of the whole design. When they're absent, no game. When I have hardened, I inevitably have paxctl-ng and possibly other xattr-setters. When I then switch to non-h, all these tools are gone the moment I run -uDN and --depclean for the first time. Unless I happen to have USE=xattr set manually or some xattr-setter installed manually through @world. (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > I'm confused. In 464932#c2 you said that non-hardened people need PaX > > > markings just as much as hardened people do. Actually, that's the reason why > > > you'd closed bug 464932 with its original purpose ("pax-utils.eclass > > > attempts to set PaX markings on non-hardened profile"), if I'm getting > > > things. > > > > No, non-hardened profiles don't *need* PaX markings, but they could use pax > > markings if they switched in the future. This would save the problem of > > redoing the markings. > > OK, non-h profiles don't need the markings at the moment, but you want those > profiles to have the markings anyway. That's why you made the eclass such > that it sets the xattrs even on non-h. You intend for the non-h people to > have the markings, you instruct the eclass to call the appropriate commands, > but you don't pull those commands' binaries into the system. That way, all > your efforts and intentions for the markings are in vain, because the actual > xatrr-setters are a bottleneck of the whole design. When they're absent, no > game. Users who don't want all those dependencies and get them anyhow will be unhappy and will make the counter argument: why are you making us pull in all this stuff we don't need. (In reply to comment #8) > (In reply to comment #7) > > OK, non-h profiles don't need the markings at the moment, but you want those > > profiles to have the markings anyway. That's why you made the eclass such > > that it sets the xattrs even on non-h. You intend for the non-h people to > > have the markings, you instruct the eclass to call the appropriate commands, > > but you don't pull those commands' binaries into the system. That way, all > > your efforts and intentions for the markings are in vain, because the actual > > xatrr-setters are a bottleneck of the whole design. When they're absent, no > > game. > > Users who don't want all those dependencies and get them anyhow will be > unhappy and will make the counter argument: why are you making us pull in > all this stuff we don't need. I see, you'd like for those people to have the marks, so you changed the eclass accordingly, but don't force the marks on them if they don't have a tool. In that case, this is an invalid bug. But it'd be useful to give the users that have no xattr-setter a hint about why they might want to set USE=xattr for portage(?) or install elfix or something by hand. I mean a hint in the ewarn that's printed when xattr setting fails because of a missing tool. (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > OK, non-h profiles don't need the markings at the moment, but you want those > > > profiles to have the markings anyway. That's why you made the eclass such > > > that it sets the xattrs even on non-h. You intend for the non-h people to > > > have the markings, you instruct the eclass to call the appropriate commands, > > > but you don't pull those commands' binaries into the system. That way, all > > > your efforts and intentions for the markings are in vain, because the actual > > > xatrr-setters are a bottleneck of the whole design. When they're absent, no > > > game. > > > > Users who don't want all those dependencies and get them anyhow will be > > unhappy and will make the counter argument: why are you making us pull in > > all this stuff we don't need. > > I see, you'd like for those people to have the marks, so you changed the > eclass accordingly, but don't force the marks on them if they don't have a > tool. In that case, this is an invalid bug. But it'd be useful to give the > users that have no xattr-setter a hint about why they might want to set > USE=xattr for portage(?) or install elfix or something by hand. I mean a > hint in the ewarn that's printed when xattr setting fails because of a > missing tool. I agree on the hint. Right now I'm waiting to see all the issue that come up as a result of the introduction of the eclass. I will then document and implement round 2. (In reply to Anthony Basile from comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #7) > > > > OK, non-h profiles don't need the markings at the moment, but you want those > > > > profiles to have the markings anyway. That's why you made the eclass such > > > > that it sets the xattrs even on non-h. You intend for the non-h people to > > > > have the markings, you instruct the eclass to call the appropriate commands, > > > > but you don't pull those commands' binaries into the system. That way, all > > > > your efforts and intentions for the markings are in vain, because the actual > > > > xatrr-setters are a bottleneck of the whole design. When they're absent, no > > > > game. > > > > > > Users who don't want all those dependencies and get them anyhow will be > > > unhappy and will make the counter argument: why are you making us pull in > > > all this stuff we don't need. > > > > I see, you'd like for those people to have the marks, so you changed the > > eclass accordingly, but don't force the marks on them if they don't have a > > tool. In that case, this is an invalid bug. But it'd be useful to give the > > users that have no xattr-setter a hint about why they might want to set > > USE=xattr for portage(?) or install elfix or something by hand. I mean a > > hint in the ewarn that's printed when xattr setting fails because of a > > missing tool. > > I agree on the hint. Right now I'm waiting to see all the issue that come > up as a result of the introduction of the eclass. I will then document and > implement round 2. The current pax-utils.eclass has fallbacks for both pt and xattr pax markings with warnings etc. I think its time to close this bug. |
