Bug 905027 - uuidd: /usr/sbin/uuidd has incorrect file permissions
Summary: uuidd: /usr/sbin/uuidd has incorrect file permissions
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: e2fsprogs
Version: 5.9
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: dhe
URL:
Whiteboard:
Depends On: 905008
Blocks: 1049888
TreeView+ depends on / blocked
 
Reported: 2013-01-28 12:10 UTC by Florian Weimer
Modified: 2014-09-16 00:24 UTC (History)
3 users (show)

Fixed In Version: e2fsprogs-1.39-37.el5
Doc Type: Bug Fix
Doc Text:
Clone Of: 905008
Environment:
Last Closed: 2014-09-16 00:24:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1222 0 normal SHIPPED_LIVE e2fsprogs bug fix update 2014-09-16 04:15:38 UTC

Description Florian Weimer 2013-01-28 12:10:22 UTC
+++ This bug was initially created as a clone of Bug #905008 +++

Description of problem:

The file /usr/sbin/uuidd should be owned by root.root:

-rwxr-xr-x. 1 uuidd uuidd 28464 Dec  3 18:54 /usr/sbin/uuidd


Version-Release number of selected component (if applicable):

uuidd-1.39-35.el5.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. ls -l /usr/sbin/uuidd
  
Actual results:

File is owned by uuidd.uuidd.

Expected results:

File is owned by root.root.

Additional info:

The init script drops permissions before calling the binary file, so there is no privilege escalation uuidd -> root.

Comment 1 Eric Sandeen 2013-01-28 20:38:10 UTC
Dumb question perhaps, but can you explain why this is a *bug* ?  Is there some actual problem here, other than proliferation of UIDs?  I don't know for sure that dropping a UID is something we can do in RHEL6 at this point, is there some policy?

Comment 2 Florian Weimer 2013-01-29 08:57:10 UTC
I think this is a bug because /usr/sbin is on root's path, and the program might be executed directly by root.  As the binary is writable by the uuidd user and thus could have been modified, this might allow the uuidd user to gain root privileges.

The separate account is harmless, and it allows the daemon to run with reduced privileges.  I don't think we can safely remove UIDs because we'd have to scan the entire file system for remaining uses, which is impractical.  Without that, the UID might get reused in the passwd database, potentially causing a security leak.

Comment 5 RHEL Program Management 2013-05-01 07:21:06 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 9 errata-xmlrpc 2014-09-16 00:24:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1222.html


Note You need to log in before you can comment on or make changes to this bug.