Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 117335 - Portage should not abort on trivial rpath issues, only on serious ones
Summary: Portage should not abort on trivial rpath issues, only on serious ones
Status: RESOLVED DUPLICATE of bug 124962
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-01 03:38 UTC by Thierry Carrez (RETIRED)
Modified: 2006-03-06 09:35 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuild.sh diff to fix insecure rpaths (ebuild.sh.diff,1005 bytes, patch)
2006-03-04 20:49 UTC, Kelly Price
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thierry Carrez (RETIRED) gentoo-dev 2006-01-01 03:38:51 UTC
The recent addition of pax-utils as a portage dep enabled massive rpath qa checking to take place. Portage aborts when it finds an exploitable rpath in an executable.

In general it's a good thing, since those issues are serious and must be fixed. Reality is a little different though : lots of stable packages are now broken and  95% of the problems are in fact about /var/tmp/portage relative rpaths, which can only be exploited by the "portage" group, so we take a very serious action (aborting the emerge of a stable package) for a very trivial problem (potential local privilege escalation by a member of an already-privileged group).

This QA check should only abort on serious rpath problems, and leave the /var/tmp/portage relative issues as a QA warning.

Not sure who handles this, ccing solar/vapier and security.
Comment 1 solar (RETIRED) gentoo-dev 2006-01-01 06:58:17 UTC
I think it would be to risky to not abort. Users and devs often 
rm -rf /var/tmp/portage and wont always remeber todo rm -rf /var/tmp/portage/*
 
How about if chrpath is installed (and fixrpaths is in FEATURES?)
we autofix the elf in question and not abort? maybe something like this


Index: ebuild.sh
===================================================================
--- ebuild.sh	(revision 2515)
+++ ebuild.sh	(working copy)
@@ -1042,7 +1042,13 @@
 			echo " http://bugs.gentoo.org/81745"
 			echo "${f}"
 			echo -ne '\a\n'
-			insecure_rpath=1
+			if hasq fixrpaths ${FEATURES} && type -p chrpath > /dev/null; then
+				for x in ${f}; do
+					chrpath -d "${x}"
+				done
+			else
+				insecure_rpath=1
+			fi
 		fi
 
 		# Check for setid binaries but are not built with BIND_NOW
Comment 2 solar (RETIRED) gentoo-dev 2006-01-01 07:21:36 UTC
Or we could make it autofix whenever chrpath is installed and stricter is not set.

+	if ! hasq stricter ${FEATURES} && type -p chrpath > /dev/null; then
Comment 3 SpanKY gentoo-dev 2006-01-01 13:23:46 UTC
yeah, assuming that /var/tmp/portage will always exist and be restricted to portage users is too much as solar points out, a lot of people casually punt it
Comment 4 Thierry Carrez (RETIRED) gentoo-dev 2006-01-02 02:05:31 UTC
I agree the right solution would be to create bugs and to fix them quickly, but that doesn't happen.

Having the autofix workaround could limit the impact on stable portage, but it would still not look too good.

The real challenge is to fix them, as most people (me included) don't have the slightest clue on how to do it. So they pile up, unfixed...
Comment 5 solar (RETIRED) gentoo-dev 2006-01-08 18:47:56 UTC
(In reply to comment #4)

> The real challenge is to fix them, as most people (me included) don't have the
> slightest clue on how to do it. So they pile up, unfixed...

So what do you want todo here?
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2006-01-09 01:49:31 UTC
(In reply to comment #5)
> So what do you want todo here?

Maybe have someone clueful coordinate the bugs in the newly-created "Runpath issues" component, meaning assigning severity based on accessibility of the vulnerable path, helping maintainers to fix them, making them care about them and educating them in case of need... The usual suspects^H^H^HGLSA Coordinators seem to be pretty clueless beyond severity rating so we might need your help. vapier seems to have taken a few of those already, and mcummings could be persuaded to solve once and for all the Perly things which seem to represent about half of the issues...

If we can solve them quickly enough, then the autofix may not be needed... But I would still provide some simple way for users to override the blocking. Like a FEATURE="IWontremoveVarTmpPortageAndITrustMyPortageGroup"

Comment 7 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-01-26 15:44:10 UTC
Personally a "big scary warning" saying to file a bug is about the best you should expect.  Portage shouldn't be dying due to insecure runpath issues.  Especially when there is no current way to get around it (besides gutting that stuff from ebuild.sh).  In the end most users aren't going to be able to fix anything, they will just report on it, and you will have to file bugs against the maintainers or fix it yourself, thats just how it will end up ;)

I don't particularly want to see another "FEATURE" just to cover this case either.  It's a bit sloppy.
Comment 8 SpanKY gentoo-dev 2006-01-27 13:22:58 UTC
> Personally a "big scary warning" saying to file a bug is about the best you
> should expect.  Portage shouldn't be dying due to insecure runpath issues.

it should actually
 
> Especially when there is no current way to get around it (besides gutting that
> stuff from ebuild.sh).

`scanelf -Xr` fixes insecure runpaths now
Comment 9 Emil Palm 2006-02-21 23:49:18 UTC
(In reply to comment #8)
> > Personally a "big scary warning" saying to file a bug is about the best you
> > should expect.  Portage shouldn't be dying due to insecure runpath issues.
> 
> it should actually
> 
> > Especially when there is no current way to get around it (besides gutting that
> > stuff from ebuild.sh).
> 
> `scanelf -Xr` fixes insecure runpaths now
> 

What is the correct command for scanelf -Xr ? What Args should you use?
Comment 10 solar (RETIRED) gentoo-dev 2006-02-22 04:38:12 UTC
scanelf -Xr /PATH/TO/EXECUTABLE 
Comment 11 Kelly Price 2006-03-04 20:21:11 UTC
I just tried the scanelf -Xr, and it doesn't work (it only prints and assumes the RPATH is correct).

I don't like chrpath -d "${x}" in this situation -- it removes the RPATH, which may have validity besides the fact that it has ${BUILDDIR} in it, and maybe some null directories.  Instead, try this (line 1043 of my current Portage install):

        if type -p scanelf > /dev/null ; then
                # Make sure we disallow insecure RUNPATH/RPATH's
                # Don't want paths that point to the tree where the package was built
                # (older, broken libtools would do this).  Also check for null paths
                # because the loader will search $PWD when it finds null paths.
                f=$(scanelf -qyRF '%r %p' "${D}" | grep -E "(${BUILDDIR}|: |::|^ )")
                if [[ -n ${f} ]] ; then
                        echo -ne '\a\n'
                        echo "QA Notice: the following files contain insecure RUNPATH's"
                        echo " Please file a bug about this at http://bugs.gentoo.org/"
                        echo " For more information on this issue, kindly review:"
                        echo " http://bugs.gentoo.org/81745"
                        echo "${f}"
                        echo -ne '\a\n'
                        # BEGIN TYGRIS PATCH
                        if hasq fixrpaths ${FEATURES} && type -p chrpath > /dev/null; then
                                # Try to intelegently fix these files.
                                # Unfortunately, scanelf is no use, and chrpath is the
                                # better tool for the job.
                                xrpath='';
                                for x in ${f}; do 
                                        if [ -f "${x}" ]; then
                                                # Assume xrpath is assigned and done.
                                                echo chrpath -r "${xrpath}" "${x}"
                                        else
                                                # Fix xrpath
                                                xrpath=''
                                                for y in ${x//:/ } ; do
                                                        if [ -n "${y}" -a "${y}" != "${BUILDDIR}" ] ; then
                                                                xrpath="${xrpath}:${y}"
                                                        fi
                                                done
                                                
                                                # Remove front colon
                                                xrpath=${xrpath/#:/}
                                        fi
                                done
                        fi
                        # die "Insecure binaries detected"
                        # END TYGRIS PATCH
                fi
Comment 12 Kelly Price 2006-03-04 20:23:21 UTC
Give me a few to throughly test it out.  I'll upload a proper patch if it works.
Comment 13 Kelly Price 2006-03-04 20:49:25 UTC
Created attachment 81365 [details, diff]
ebuild.sh diff to fix insecure rpaths

Strangely enough, with the newest version of this patch, it seems to work but not properly error out or debug.  Here's what I have.  There's an "echo" for where chrpath is called (call be paranoid).  If it works for folks here or can be adjusted, let me know.  I can't seem to find where I messed up.
Comment 14 solar (RETIRED) gentoo-dev 2006-03-05 03:58:33 UTC
scanelf looks that the env variable TMPDIR as apart of it's checks

TMPDIR=/var/tmp/portage/ scanelf -qXr /PATH/TO/EXECUTABLE 

The rpath behavior changes are handled in another bug. chrpath wont be used.
Comment 15 Thierry Carrez (RETIRED) gentoo-dev 2006-03-06 09:35:02 UTC
This will be solved by the enhancement requested in bug 124962, closing this one as dupe.

*** This bug has been marked as a duplicate of 124962 ***