Bug 646440 (removesetuid) - Remove all SETUID apps from the distribution
Summary: Remove all SETUID apps from the distribution
Alias: removesetuid
Product: Fedora
Classification: Fedora
Component: distribution
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Bill Nottingham
Depends On: 456105 646443 646444 646452 646455 646456 646461 646468 646469 646472 646474 646477 646478 646479 646484 646489 646492 646494
TreeView+ depends on / blocked
Reported: 2010-10-25 12:46 UTC by Daniel Walsh
Modified: 2014-03-17 03:25 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: removesuid16 (view as bug list)
Last Closed: 2011-04-05 13:16:58 UTC
Type: ---

Attachments (Terms of Use)

Description Daniel Walsh 2010-10-25 12:46:39 UTC
Description of problem:
This is a blocker bug for all packages that include setuid apps.

The goal is to meet the following feature.


Comment 1 Parag AN(पराग) 2010-10-28 03:39:51 UTC
 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 


Comment 2 Parag AN(पराग) 2010-10-28 04:38:29 UTC
I think Xorgperms is a toplevel macro and not a local macro for the package so %global applies here

Comment 3 Daniel Walsh 2010-10-28 13:06:51 UTC
I updated the page with further information on what I have done to remove setuid from the newrole command.

Comment 4 Tomas Mraz 2010-11-04 13:58:40 UTC
This is seriously blocked by capabilities on files unsupported by prelink (bug 456105). Prelink will remove the capabilities on files touched by it.

Comment 5 Matt Domsch 2010-12-06 04:51:26 UTC
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.

Comment 6 Daniel Walsh 2010-12-06 19:37:27 UTC
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.

Comment 7 Matt Domsch 2010-12-06 20:07:12 UTC
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.

Comment 8 Daniel Walsh 2010-12-06 21:15:37 UTC
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.

Comment 9 Matthew Miller 2011-01-05 14:26:53 UTC
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!).

Comment 10 Steve Grubb 2011-01-05 15:36:45 UTC
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.

Comment 11 Matthew Miller 2011-01-05 15:57:33 UTC
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.

Comment 12 Garrett Holmstrom 2011-02-02 01:07:05 UTC
(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.

Comment 13 Daniel Walsh 2011-02-02 13:32:29 UTC
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 14 Daniel Walsh 2011-04-05 13:16:58 UTC
Moved bugs that depended on this to Rawhide and opened a new bug for F16.

So we can mark this feature complete.

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