Hide Forgot
Description of problem: This is a blocker bug for all packages that include setuid apps. The goal is to meet the following feature. https://fedoraproject.org/wiki/Features/RemoveSETUID
I think either feature page or tracker bug should give example on how to remove setuid. Also examples given in individual bugs uses %define instead of %global whereas guidelines says http://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
I think Xorgperms is a toplevel macro and not a local macro for the package so %global applies here
I updated the page with further information on what I have done to remove setuid from the newrole command.
This is seriously blocked by capabilities on files unsupported by prelink (bug 456105). Prelink will remove the capabilities on files touched by it.
Note, this causes my full rawhide rebuilds to go considerably slower. From under 24 hours for a full rebuild of all 10k packages, to 4 days. This is due to tmpfs not being able to handle capabilities.
Matt I understand, not sure what to do about it. Does the actual mock environment blow up when rpm tries to install on a system that does not support file caps? Maybe the solution is to have rpm complain but succeed in installing. Prelink problem has supposedly been fixed.
Installing RPMs with SUID apps (policycoreutils, iputils) fails when setting up the buildroot, before it even tries executing the rpmbuild. So yes, RPM is failing at cpio unpack on those suid files.
We have an open bug report with Panu to have a fall back in this case to either setuid or drop file caps altogether. In this case the latter would be preferable.
Take a look at: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 by Brad Spengler, "False Boundaries and Arbitrary Code Execution". In summary, 20 of the 35 capabilities bits allow actions that can result in root privileges from an exploitable program. I propose that we modify this feature to remove setuid only from binaries requiring only capabilities that are on the remaining list of 15. The remaining binaries should be left setuid, which is more transparent to admins (improving security through obviousness!).
In reply to comment #9, what that article does is simply round up examples for people that don't connect what's written in /usr/include/linux/capability.h with where it gets used. What's said is not really new, but its increasing awareness for people which is good. More eyes looking is better. The alternative is to run the app with root privs and therefore represents the already compromised state that Brad tries to evoke. In terms of obviousness, ls still uses color to show files with capabilities as it would setuid. There is a filecap program that can scan a system to show files with capabilities. tar can capture capabilities for backups. And there is also pam_cap to limit capabilities of sessions during login. We also know of several apps that simply cannot be changed because it doesn't make sense. But the rest can be changed.
They can be changed, but if it gives no meaningful security advantage to so, is there a reason to? If a program is setuid, it is obvious on looking at it that compromise of that program can lead to full system compromise. If it is just shown as having certain capabilities, it's reasonable for an admin to assume that compromise of that program will be still contained in some way. Since that's not the case for most capabilities, it seems better to just leave them setuid, unless it can be demonstrated that for that particular program the given capabilities do not effectively equal root access anyway.
(In reply to comment #11) > If a program is setuid, it is obvious on looking at it that compromise of that > program can lead to full system compromise. If it is just shown as having > certain capabilities, it's reasonable for an admin to assume that compromise of > that program will be still contained in some way. Perhaps it would help to have the various ways of looking at files (i.e. ls) always display when a file has capability attributes assigned to it.
Sysadmins should assume an executable with capabilities that is compromised can take over the system, just like setuid. Using file capabilities in some cases t lessons the risk, all applications that use capabilities permissions should drop their capabilities as soon as they do not need them. Tools like ls show the same basic indication that setuid does as far as the color being red. I guess I should open bugs on find to look for files with file capabilities. Some great tools to look at capabilities are available pscap, filecap, netcap,
Moved bugs that depended on this to Rawhide and opened a new bug for F16. So we can mark this feature complete.