Bug 646494

Summary:	Replace SETUID in spec file with the correct file capabilities.
Product:	[Fedora] Fedora	Reporter:	Daniel Walsh <dwalsh>
Component:	usermode	Assignee:	Miloslav Trmač <mitr>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	dwalsh, mgrepl, mitr, sgrubb, tmraz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	646443	Environment:
Last Closed:	2010-10-25 18:43:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	646440

Description Daniel Walsh 2010-10-25 13:42:56 UTC

+++ This bug was initially created as a clone of Bug #646443 +++

Description of problem:

Please remove setuid setup of files in your package with file capabilities.

This is to satisfy the F15 feature.

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

An example of how this was done for X is.


%if 0%{?fedora} < 15
%define Xorgperms %attr(4711, root, root)
%else
%define Xorgperms %attr(0711,root,root) %caps(cap_sys_admin,cap_sys_rawio,cap_dac_override=pe)
%endif

Comment 1 Miloslav Trmač 2010-10-25 17:02:37 UTC

*** Bug 646452 has been marked as a duplicate of this bug. ***

Comment 2 Miloslav Trmač 2010-10-25 18:43:53 UTC

Besides using PAM to authenticate and modifying /etc/passwd and /etc/shadow, userhelper is primarily a generic privilege escalation mechanism, running a process as root user with all capabilities.

Given that userhelper has to be able to grant full privileges and all capabilities, a successful attack on userhelper will give the attacker full privileges and all capabilities.  There is therefore very little scope for security improvement by dropping capabilities in userhelper, whereas the potential for breakage and introducing new security holes is quite large.

For example, if userhelper were no longer setuid, would it create new versions of /etc/shadow owned by the invoking user?

Given the above, and the fact that Linux is increasingly using PolicyKit, I don't think the necessary code review and research (of both userhelper and all used libraries) is worth the effort and the risk.

Comment 3 Daniel Walsh 2010-10-25 19:29:45 UTC

Seems like a valid argument.