Bug 646484

Summary:	Replace SETUID in spec file with the correct file capabilities.
Product:	[Fedora] Fedora	Reporter:	Daniel Walsh <dwalsh>
Component:	passwd	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	dwalsh, matt, mgrepl, 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 19:41:50 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:33:55 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 Tomas Mraz 2010-10-25 19:41:50 UTC

passwd must be effective uid 0 to be able to replace /etc/shadow with a new copy.

Comment 2 Steve Grubb 2010-10-26 20:28:42 UTC

Are you sure that DAC_OVERRIDE isn't all that's needed?

Comment 3 Tomas Mraz 2010-10-27 07:07:27 UTC

Yes, I am. Even with CAP_CHOWN it is not much better as you cannot create the new /etc/shadow as a regular user because that creates a race during which the user can replace root's password hash with arbitrarily chosen value allowing him to log in. Also other pam modules might depend on other capabilities and can have similar induced vulnerabilities as the pam_unix would have.

Comment 4 Matt McCutchen 2011-05-27 14:03:06 UTC

(In reply to comment #1)
> passwd must be effective uid 0 to be able to replace /etc/shadow with a new
> copy.

I guess the solution would be to allocate a new user "shadow" to own the file and make passwd setuid to that user, unless non-root ownership of /etc/shadow would upset other programs.

(In reply to comment #3)
> Also other pam modules might depend on other capabilities

I guess if we cared enough, we could move each feature that requires unusual capabilities into a helper executable with those capabilities, but at some cost in performance and convenience.

Would it make sense to exempt all programs whose operation involves calling arbitrary PAM modules from the remove-setuid project?

Comment 5 Daniel Walsh 2011-05-31 16:06:35 UTC

Probably.