Bug 693731 (removesuid16)

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

https://fedoraproject.org/wiki/Features/RemoveSETUID

--- Additional comment from panemade 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 

http://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define

--- Additional comment from panemade 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 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 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 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 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 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 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 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 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 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 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 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,