<!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. -->

<!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. -->

−

File Capabilities have been present in the Operating System for a few releases now, it is time that we remove as many setuid applications as we can and just assign the capabilities required by an application. The goal is to make the applications and the Operating System more secure.

+

File Capabilities have been present in the Operating System for a few releases now, it is time that we remove as many setuid applications as we can and just assign the capabilities required by an application. The goal is to make the applications and the Operating System more secure. Simultaneous with removing SETuid capabilities, we examined lots of setuid apps to make sure they drop the capabilities when they no longer needed them.

File Capabilities have been present in the Operating System for a few releases now, it is time that we remove as many setuid applications as we can and just assign the capabilities required by an application. The goal is to make the applications and the Operating System more secure. Simultaneous with removing SETuid capabilities, we examined lots of setuid apps to make sure they drop the capabilities when they no longer needed them.

We need to change the spec files of most applications that include a setuid application to remove the setuid flag and change to file capabilities.

Package maintainers after making this change have to verify that their applications still work without the setuid app. In some cases this might not be possible.

Cases where you are an admin becoming root, su, sudo, ksu, userhelper will not be able to change. But I think all package maintainers should take a look at their setuid apps and see if they can do a better, more secure job using file capabilities.

Steve Grubb is a great source of information on handling capabilities.

If your setuid app is covered by SELinux policy we know in the rules which capabilities are used in the application, so you can work with the SELinux team to get the list.

One example newrole needs to send audit messages, (cap_audit_write) but when we coded it up originally it was setuid root which means it started as UID=0 and needed to execute the setuid(USERID) system call to change the UID back to the calling process, this caused newrole to require the cap_setuid capability. Then newrole dropped capabilities requiring the cap_setpcap capability. By changing to use file capabilities, I was able to give newrole just cap_audit_write and drop the
code to change the setuid and drop capabilities, eliminating the need for these capabilities. Now I can write tighter SELinux policy on newrole and only allow cap_audit_write.

Here is the patch of what I changed in the spec file for policycoreutils.

Other tools for examining processes are available, you might want to look at libcap and the libcap-ng-utils RPMs which provides a bunch of useful tools for this, getcap, filecap, netcap, pscap, etc. See also

Open up a tracker bug, then open a bugzilla on every package that includes setuid applications. We would like to have the Fedora packaging committee codify this in rules and perhaps rpmlint to have smarts about identifying setuid apps and recommending file capabilities.

Do a complete install of all Fedora packages and then search for any applications that have the setuid flag. If they do then the Feature is not complete. For any application that was setuid and now uses file capabilities, we need to test that the applications still works as it used to. Test rpmlint on an spec file containing a setuid app, and make sure it prints a proper warning.