Bug 649256

Summary: glibc: disable $ORIGIN expansion for privileged programs
Product: Red Hat Enterprise Linux 4 Reporter: Tomas Hoger <thoger>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED WONTFIX QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 4.8CC: fweimer, pmuller, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-19 10:26:37 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: 667974    

Description Tomas Hoger 2010-11-03 11:13:57 UTC
Description of problem:
A security flaw in the way glibc's ld.so processed LD_AUDIT contained $ORIGIN (see bug #43306) led to disabling $ORIGIN expansion in privileged programs completely in EL5 and later (bug #643306, comment #26).

As EL4 glibc does not support linker auditing API, hence it did not require immediate security fix as was issued for EL5.  In EL4, $ORIGIN expansion may happen if privileged program is built with RPATH containing $ORIGIN.  No setuid/setgid binary in EL4 does that.  Disabled expansion can provide a safety check for such unsafe setuid/setgid binaries.

Version-Release number of selected component (if applicable):
glibc-2.3.4-2.43.el4_8.6

Steps to Reproduce:
See reproducer in bug #643306, comment #23.

Comment 1 Tomas Hoger 2010-12-08 17:45:46 UTC
(In reply to comment #0)
> See reproducer in bug #643306, comment #23.

Updated test case in bug #643306, comment #39.

Comment 2 Tomas Hoger 2011-01-12 14:16:28 UTC
"Don't ignore $ORIGIN in libraries" fix does not help either, see test case in bug #667974.

Comment 3 Tomas Hoger 2011-01-12 15:16:20 UTC
-> ASSIGNED

The aim of this bug is to provide extra safety for privileged programs that happen to have $ORIGIN in RPATH.  If we consider such binaries to be inherently broken (as bug #667974, comment #8 suggests), we should revert the patch that was applied and close this wontfix.  The patch does not make it harder to abuse such privileged programs, but rather remove certain constraints.  Do you agree that such change is undesired?