Bug 566174

Summary:	www-client/google-chrome-unstable: setuid sandbox using RPATH=$ORIGIN again
Product:	Gentoo Linux	Reporter:	Mike Gilbert <floppym>
Component:	Current packages	Assignee:	Chromium Project <chromium>
Status:	RESOLVED FIXED
Severity:	normal	CC:	phajdan.jr, vapier
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
URL:	https://code.google.com/p/chromium/issues/detail?id=556843
See Also:	http://code.google.com/p/chromium/issues/detail?id=556843
Whiteboard:
Package list:		Runtime testing required:	---

Description Mike Gilbert gentoo-dev

2015-11-19 02:31:49 UTC

I'm getting the following failure when installing google-chrome-unstable:

 * Messages for package www-client/google-chrome-unstable-48.0.2564.8_p1:

 * QA Notice: The following files contain insecure RUNPATHs
 *  Please file a bug about this at http://bugs.gentoo.org/
 *  with the maintaining herd of the package.
 * $ORIGIN/ /tmp/portage/www-client/google-chrome-unstable-48.0.2564.8_p1/image/opt/google/chrome-unstable/chrome-sandbox
 * ERROR: www-client/google-chrome-unstable-48.0.2564.8_p1::gentoo failed:
 *   Aborting due to serious QA concerns with RUNPATH/RPATH

I think is complaining about RPATH=$ORIGIN/ in the chrome-sandbox binary.

10executable-issues has this code segment:

>    # Reject set*id binaries with $ORIGIN in RPATH #260331
>    x=$(
>        find "${ED}" -type f \( -perm -u+s -o -perm -g+s \) -print0 | \
>        xargs -0 scanelf -qyRF '%r %p' | grep '$ORIGIN'
>    )

Bug 260331 says that normal users may create hard links to suid binaries, and these hard links maintain suid permissions. This is a problem since $ORIGN may be manipulated by a normal user.

I just tested this on Linux 4.1.6, and I'm getting "Operation not permitted" when I try to create a hard link to any file owned by another user. So, the security problem posed in that bug seems to have been addressed in the kernel at some point.

Is this QA check still relevant? Or can we remove it?

Comment 1 Mike Gilbert gentoo-dev

2015-11-19 03:13:25 UTC

As a workaround, I'm stripping the RPATH from the chrome-sandbox binary with chrpath. It wasn't needed anyway.

Comment 2 SpanKY gentoo-dev

2015-11-19 05:43:13 UTC

i imagine that's a kernel setting because i can create hard links just fine to setuid files.  even then, there's no guarantee the system won't run an older kernel which doesn't block it.

ignoring that, use of $ORIGIN in set*id programs is still banned.  it doesn't make sense and is simply a bad idea.

see this upstream bug report about getting it fixed:
http://crbug.com/556843

Comment 3 Mike Gilbert gentoo-dev

2017-05-18 21:27:36 UTC

This was fixed some time ago upstream.