Bug 693731 - (removesuid16) Remove all SETUID apps from the distribution
Remove all SETUID apps from the distribution
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Radek Vokal
Radek Vokal
: Tracking
Depends On: 646476 646447 646448 646450 646458 646462 646466 646467 646471 646480 646481 646482 646485 646487 646490 646491 646493 646495 648653 689564 771134
  Show dependency treegraph
Reported: 2011-04-05 09:06 EDT by Daniel Walsh
Modified: 2015-02-17 08:42 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: removesetuid
Last Closed: 2015-02-17 08:42:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2011-04-05 09:06:59 EDT
+++ This bug was initially created as a clone of Bug #646440 +++

Description of problem:
This is a blocker bug for all packages that include setuid apps.

The goal is to meet the following feature.


--- Additional comment from panemade@gmail.com on 2010-10-27 23:39:51 EDT ---

 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 


--- Additional comment from panemade@gmail.com on 2010-10-28 00:38:29 EDT ---

I think Xorgperms is a toplevel macro and not a local macro for the package so %global applies here

--- Additional comment from dwalsh@redhat.com on 2010-10-28 09:06:51 EDT ---

I updated the page with further information on what I have done to remove setuid from the newrole command.

--- Additional comment from tmraz@redhat.com on 2010-11-04 09:58:40 EDT ---

This is seriously blocked by capabilities on files unsupported by prelink (bug 456105). Prelink will remove the capabilities on files touched by it.

--- Additional comment from matt_domsch@dell.com on 2010-12-05 23:51:26 EST ---

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.

--- Additional comment from dwalsh@redhat.com on 2010-12-06 14:37:27 EST ---

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.

--- Additional comment from matt_domsch@dell.com on 2010-12-06 15:07:12 EST ---

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.

--- Additional comment from dwalsh@redhat.com on 2010-12-06 16:15:37 EST ---

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.

--- Additional comment from mattdm@mattdm.org on 2011-01-05 09:26:53 EST ---

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!).

--- Additional comment from sgrubb@redhat.com on 2011-01-05 10:36:45 EST ---

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.

--- Additional comment from mattdm@mattdm.org on 2011-01-05 10:57:33 EST ---

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.

--- Additional comment from gholms@fedoraproject.org on 2011-02-01 20:07:05 EST ---

(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.

--- Additional comment from dwalsh@redhat.com on 2011-02-02 08:32:29 EST ---

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,
Comment 1 Ian Dall 2011-12-02 23:28:41 EST
This effectively breaks using nfs or any filesystem which does not support capabilities. Certainly I can work around by finding all the files with a capability and making them SUID, but a) that is likely to break every time I do an update and b) I should audit each of them to make sure that they were (and remain) suid safe. And if they are suid safe why bother with capabilities?

I guess the correct fix would be to make nfs support capabilities. This will probably never happen for nfs3. For nfs4 it looks possible at least, but it still would require significant work upstream, which as best I can tell there are no plans for. I could file a bug for nfs, but I suspect that is not likely to do much good.

This change to use capabilities looks premature to me, but a way forward would be to have a configurable flag for rpm and require packages to test for the flag rather than for %if 0%{?fedora} < 15 falling back to suid if appropriate and capabilities are not supported. 

I guess nfs mounting "system" partitions is not that popular, but I find a shared readonly nfs root to be efficient and effective. The only real downside being is is not that well supported :-(
Comment 2 Wolfgang Denk 2012-01-05 07:01:22 EST
Please also keep in mind that all tools that are used to copy / backup / restore
files must be capable of correctly handling capabilities, and if they need
special options to do so, then all backup scripts etc. need to be adapted as

Fedora 16 has already caused problems because standard tools like bacula, cpio
or rsync don't handle this well, see bug # 771134
Comment 3 Daniel Walsh 2012-01-05 10:26:32 EST
Sadly that is true, but this is also a catalist to cause these bugs to be fixed, rather then to remain broken forever.
Comment 4 Simone Caronni 2012-01-20 11:15:23 EST
Bacula rawhide 5.2.4 handles file capabilities correctly:
Comment 5 David Keegan 2012-06-11 17:30:54 EDT
While I agree with the removal of setuid in principle, to do it BEFORE the various utilities (tar etc) support capabilities seems premature and very user-unfriendly.

I used to be able to reliably backup and restore my system using tar. Now in Fedora17 various utilities in a restored system don't work.
Comment 6 Daniel Walsh 2012-06-13 17:36:36 EDT
David which application are you using that does not support file capabilities?  Did you open a bugzilla on them?
Comment 7 David Keegan 2012-06-13 17:53:04 EDT
The application is tar, and I was about to open a bug but found the issue has already been raised in bug 771134. I've tried tar's --xattrs option (Fedora 17) but it just doesn't preserve the file capabilities such that utilities like ping, ping6, work after backing up and restoring the system partition.

I rely heavily on being able to restore my system partition from a backup. Now it's guaranteed to be broken after a restore and I have to fiddle with setting file capabilities to get it working again.
Comment 8 Daniel Walsh 2012-06-14 15:50:17 EDT
Well that bug says bacula was fixed but not tar?  Can you open a bug on tar?
Comment 9 David Keegan 2012-06-15 13:24:44 EDT
A separate bug 771927 already covers the tar issue.
Comment 10 Daniel Walsh 2012-06-15 15:58:28 EDT
Ok I updated the bug.  Lets follow up in a week if nothing happens.
Comment 11 Fedora End Of Life 2013-04-03 14:09:40 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
Comment 14 Fedora End Of Life 2015-01-09 11:37:55 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 Fedora End Of Life 2015-02-17 08:42:38 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.