(Created page with '{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To rea...') |
|||
| (21 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
= Replace setuid apps where possible with file capabilities<!-- The name of your feature --> = | |||
= | |||
== Summary == | == Summary == | ||
<!-- 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. Simultaneous with removing SETuid capabilities, we examined lots of setuid apps to make sure they drop the capabilities when they no longer needed them. | |||
== Owner == | == Owner == | ||
<!--This should link to your home wiki page so we know who you are--> | <!--This should link to your home wiki page so we know who you are--> | ||
* Name: [[User: | * Name: [[User:dwalsh| Daniel Walsh]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--> | <!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--> | ||
* Email: < | * Email: <dwalsh@redhat.com> | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/15 | Fedora 15 ]] | ||
* Last updated: | * Last updated: 2011-4-5 | ||
* Percentage of completion: | * Percentage of completion: 100% | ||
* Tracker Bug https://bugzilla.redhat.com/show_bug.cgi?id=646440 added | |||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
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. | |||
http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch | |||
Dan Berrange points out. | |||
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 | |||
http://people.redhat.com/sgrubb/libcap-ng/index.html | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--> | ||
This will benefit Fedora by making it more secure. | |||
== Scope == | == Scope == | ||
<!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
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. | |||
== How To Test == | == How To Test == | ||
| Line 53: | Line 65: | ||
3. What are the expected results of those actions? | 3. What are the expected results of those actions? | ||
--> | --> | ||
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. | |||
== User Experience == | == User Experience == | ||
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
No change in User Experience should be expected. | |||
== Dependencies == | == Dependencies == | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | ||
We have a dependency that every package that contains a setuid app, is changed by the package owner. Although if we get some/most packages we feel that we have improved the security of the system. | |||
== Contingency Plan == | == Contingency Plan == | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
None Necessary | |||
== Documentation == | == Documentation == | ||
* We should change documentation on packaging guidelines to talk about using file capabilities. | |||
== Release Notes == | == Release Notes == | ||
* '''proposed draft''': Fedora 15 removes setuid applications and instead specifically assigns the capabilities required by each application. | |||
== Comments and Discussion == | == Comments and Discussion == | ||
* See [[Talk:Features/ | * See [[Talk:Features/RemoveSETUID]] | ||
[[Category: | [[Category:FeatureAcceptedF15]] | ||
<!-- When your feature page is completed and ready for review --> | <!-- When your feature page is completed and ready for review --> | ||
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | <!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | ||
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | <!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | ||
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --> | <!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --> | ||
Latest revision as of 13:47, 5 April 2011
Replace setuid apps where possible with file capabilities
Summary
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.
Owner
- Name: Daniel Walsh
- Email: <dwalsh@redhat.com>
Current status
- Targeted release: Fedora 15
- Last updated: 2011-4-5
- Percentage of completion: 100%
- Tracker Bug https://bugzilla.redhat.com/show_bug.cgi?id=646440 added
Detailed Description
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.
http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch
Dan Berrange points out.
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
http://people.redhat.com/sgrubb/libcap-ng/index.html
Benefit to Fedora
This will benefit Fedora by making it more secure.
Scope
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.
How To Test
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.
User Experience
No change in User Experience should be expected.
Dependencies
We have a dependency that every package that contains a setuid app, is changed by the package owner. Although if we get some/most packages we feel that we have improved the security of the system.
Contingency Plan
None Necessary
Documentation
- We should change documentation on packaging guidelines to talk about using file capabilities.
Release Notes
- proposed draft: Fedora 15 removes setuid applications and instead specifically assigns the capabilities required by each application.