Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#13890 - Packaging creation and rpath issues

Attached to Project: Pacman
Opened by Gerardo Exequiel Pozzi (djgera) - Friday, 20 March 2009, 23:29 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 28 April 2009, 23:53 GMT
Task Type Bug Report
Category makepkg
Status Closed
Assigned To Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity High
Priority Normal
Reported Version 3.2.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Hi,

(first: sorry my very bad english)

I see that many executables and libraries in Arch Linux don't take care about rpath in package creation step.

Then when executed, the ld-linux will find libraries first in the rpath , and if fails will go to search in the cache ld.so.cache, instead of directly search here) So for example if you execute the... setfacl/getfacl/chacl (in package from core/acl, and this is the only package in [core] that have this issue with binaries) will find in libs in varius incorrects paths for example:

$ readelf -d /usr/bin/getfacl | grep RPATH
0x0000000f (RPATH) Library rpath: [/home/thomas/arch/repos/core/base/acl/pkg/usr/lib]

$ LD_DEBUG=libs setfacl
10323: find library=libacl.so.1 [0]; searching
10323: search (*** stripped here same paths below... ***)
(RPATH from file setfacl)
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/sse2/libacl.so.1
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/libacl.so.1
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/sse2/libacl.so.1
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/libacl.so.1
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/sse2/libacl.so.1
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/libacl.so.1
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/sse2/libacl.so.1
10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/libacl.so.1
10323: search cache=/etc/ld.so.cache
10323: trying file=/lib/libacl.so.1
10323:


The issue here is for example if a user "thomas" in my system, create a libacl.so.1 in any of these paths, the setfacl will use them insteads of the correct libacl.so.1, and if the libacl.so.1 from thomas contain a malicious code, the user that execute it are in problem :(, root for example.

OK managing rpath at build time vary from package to package, some that uses autotools/libtool, the configure script, have a --disable-rpath for controling this behavior, and other don't have. Others require rpath at build time to linking executables from the same source, and other always hardcore it (gcc -Wl,--rpath...), etc, etc.
In libtool, can change a M4 macro to don't use rpath for example.

There is a simple tool, to remove rpath from ELF files called chrpath [#1] (seems that cmake build system can use an aproach based on chrpath to delete rpath from ELF)

For example:

# /bin/ls -l /usr/bin/setfacl
-rwxr-xr-x 1 root root 25052 2008-02-26 13:23 /usr/bin/setfacl
# chrpath -d /usr/bin/setfacl
# /bin/ls -l /usr/bin/setfacl
-rwxr-xr-x 1 root root 25052 2009-03-20 01:06 /usr/bin/setfacl
# LD_DEBUG=libs setfacl
11033: find library=libacl.so.1 [0]; searching
11033: search cache=/etc/ld.so.cache
11033: trying file=/lib/libacl.so.1

And now is correct and secure.

The minor problem here, _and don't make much sense_ is that will do some aditionals system calls open() and stat64() for each inexistent libs on loading.
Many others have /usr/lib (and many many others paths) as rpath, then when execute will look for the first library that need to load at /usr/lib/tls/i686/sse2:/usr/lib/tls/i686:/usr/lib/tls/sse2:/usr/lib/tls:/usr/lib/i686/sse2:/usr/lib/i686:/usr/lib/sse2 (and these are removed from search path for next libs), and then for all libs will look first in /usr/lib if fails do a /etc/ld.so.cache search.

The rpath is important when managing many versions of the same libs with same soname, for example for debuging/testing purposes, running from the builddir, etc.

For example i see googling that in some distros (like Debian[s]) and in some BSDs the rpath is removed from all ELF files, except that in that is necessary required.



Then my question: what is the position of arch-dev-team about rpath? (remember: don't take this as a mail as feature request, is just one
question)



[#1] chrpath: The original home don't work http://directory.fsf.org/project/chrpath/ i use a debian mirror in my PKGBUILD http://aur.archlinux.org/packages.php?ID=24818

This task depends upon

Closed by  Dan McGee (toofishes)
Tuesday, 28 April 2009, 23:53 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Namcap and packagers are responsible per Allan's comment.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 20 March 2009, 23:32 GMT
 FS#13891  - [acl] A trivial fix RPATH issue

This was posted originaly on arch-general ML, but by request i put here.

Daenyth Blank wrote:
>
>
> Thanks for pointing this out, it's a pretty serious security issue.
> Please file a bug on http://bugs.archlinux.org about it. Probably one
> of the better solutions would be for makepkg to strip the rpath in the
> same step where it uses "strip" to remove debugging info.
>

Allan McRae wrote:
>
> So here is what gentoo does:
>
> f=$(scanelf -qyRF '%r %p' "${D}" | grep -E "(${PORTAGE_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'
> die "Insecure binaries detected"
> fi
>
>
> I think this should be a namcap check rather than have makepkg automatically adjust these - although I could be convinced otherwise.
>
> Sacnning my computer with readelf, I found a few other packages that this effects. There are also plenty of "Library rpath: [$ORIGIN]" which I am not sure if is bad...
>
> Anyway, it would be good if you could open a bug report about this.
>
> Allan
Comment by Allan McRae (Allan) - Friday, 20 March 2009, 23:33 GMT
So, anybody have opinions on whether this should be detected and fixed in makepkg or detected in namcap and the PKGBUILD updated. I am thinking the second.
Comment by Jens Adam (byte) - Saturday, 21 March 2009, 00:14 GMT
I'd vote for namcap too.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 21 March 2009, 00:40 GMT
Hi, well i created a patch for my testing purposes only, is against the pacman.git, but if any are interested in it can use it.
It does the same as strip step but, with chrpath to remove rpath/runpath for ELF files especified at $EMPTYRPATH_DIRS

Personally i voted for removing the rpath at all (not necessary with my method proposed), except in cases that are strictly necessary, because having it, does aditionals syscalls for each library. Also is very anoying when debuging programs, having a rpath set the LD_LIBRARY_PATH is ignored at all. (see above)

Also if this feature isn't implemented i do a vote to namcap checking insecure rpaths.

[djgera@gerardo ~]$ LD_TRACE_LOADED_OBJECTS=yes LD_LIBRARY_PATH=. /usr/bin/certutil
<snip>
libnss3.so => /usr/bin/../lib/libnss3.so (0xb7f1f000)
<snip>
[root@gerardo ~]# chrpath -d /usr/bin/certutil
[djgera@gerardo ~]$ LD_TRACE_LOADED_OBJECTS=yes LD_LIBRARY_PATH=. /usr/bin/certutil
<snip>
libnss3.so => ./libnss3.so (0xb7ed9000)
<snip>


Comment by Lukas Jirkovsky (6xx) - Saturday, 21 March 2009, 07:24 GMT
I'd like to see it in makepkg as an possible parameter to option=() in PKGBUILD. Just my two cents.
Comment by Allan McRae (Allan) - Saturday, 21 March 2009, 08:21 GMT
I see that gentoo does something like:
chrpath -r /usr/lib ${BUILDDIR}/usr/lib

So, appears to redirect the RPATH to its correct place rather that deleting the entry
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 26 March 2009, 03:23 GMT
This is a complete list of uniques of all rpaths of ELF files that are in extra. Some are insecures like:

[::::::::] (a list of rpaths that all are empty)
[] (a empty rpath)
[.:/usr/lib/gcin] (rpath are the current directory)
[/usr/lib:/home/pierre/chroot/arch32-testing/packages/cinepaint/trunk/src/cinepaint-0.22-1/plug-ins/icc_examin/icc_examin] (like bug in acl  FS#13891  )
[/mnt/backup/projetos/archlinux/devel/pyqt/trunk/src/PyQt-x11-gpl-4.4.4/qpy/QtDesigner:/usr/lib] (idem up)
[/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_client/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_delta/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_fs/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_ra/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_repos/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_wc/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_diff/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/libsvn_subr/.libs:/mnt/backup/projetos/archlinux/devel/subversion/trunk/src/subversion-1.6.0/subversion/bindings/swig/perl/libsvn_swig_perl/.libs] (idem up)


PD: Allan for your question $ORIGIN means that the rpath is the path where the library is located.
Comment by Allan McRae (Allan) - Thursday, 26 March 2009, 04:58 GMT
djgera: We should open separate bug reports for the individual packages so we can keep this bug limited to how we should deal with this in makepkg. I will for the five obvious packages tonight if you have not done so but will need to know what packages the empty paths came from to fix them.
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 29 March 2009, 20:49 GMT
One [::::::::] was fixed now (kdepim) in new KDE 4.2.2 , all KDE packages are compiled without RPATH from 4.2.2  FS#13965 

I will start to open tickets now.
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 29 March 2009, 22:27 GMT
Done for rest of [extra]:  FS#14014   FS#14015   FS#14016  ( and your tickets  FS#14000   FS#14001   FS#14002   FS#14003  )
Done for all of [community] (except for binary netbeans)  FS#14017   FS#14019   FS#14020   FS#14021   FS#14022   FS#14023 
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 31 March 2009, 23:11 GMT
I created a feature request for namcap:
 FS#14049  - [namcap] should check about insecure RPATH in ELF files.

Then now, the discusion are centered for makepkg only.
Comment by Gavin Bisesi (Daenyth) - Thursday, 09 April 2009, 15:37 GMT
As I said before, I think that this should be handled in makekpg. I like Lukas' suggestion of an option for it.
Comment by Allan McRae (Allan) - Thursday, 09 April 2009, 16:03 GMT
The more I think about this, the more I believe that this is not a job for makepkg:

1) All makepkg can do is detect a bad rpath and attempt to delete it using chrpath. I really do not want chrpath to be a dep for makepkg.

2) Most of the packages that were affected by this were fixed by patching rather than using chrpath. Fixing the build process rather than hacking around it seems a far better solution

Thus, a namcap check seems the best method to me. I'm going to need a lot of convincing to have this added to makepkg...
Comment by Gavin Bisesi (Daenyth) - Thursday, 09 April 2009, 16:15 GMT
Fair enough. I think that regardless of the implementation (or lack thereof) in makepkg, it should be in namcap. Fixing it in the build process is better, definitely. Since frankly I'm not going to lift a finger to help implement it in makepkg, I'll back your judgement on this :)
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 09 April 2009, 16:51 GMT
@Allan: OK, i have one question: what is your position about ELF that have correct (non-insecure) RPATH like "/usr/lib"? as i said above have two problems

1) Can't use LD_LIBRARY_PATH with this (for example for debuggin purposes)
2) A bit of overhead in locating every library that tries to load in inexistent directories (syscalls open() and stat64() for each "hardware capability mask" LD_HWCAP_MASK and TLS)

Removing theses rpaths or not? (with some "hacks" at build time, depending of the build system used, most of the problem here is libtool) So for each package that can be fixed can open a ticket with "low severity".
Comment by Allan McRae (Allan) - Friday, 10 April 2009, 03:34 GMT
@djgera: I agree it would be best for the RPATH to be blank. File a bug report for those packages (at Very Low priority) only if you can provide a build fix. I don't think maintainers will be motivated to find fixes for things that are not "real bugs"...
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 19 April 2009, 00:26 GMT
OK Allan, I will start for packages that can be fixed in "trivial way". Like a simple "sed" replacement or that uses cmake build system. For example for those that uses libtool, after the configure script a line like this:

sed 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=" "|' -i libtool

Then libtool don't put RPATH in ELF files.
Comment by Allan McRae (Allan) - Tuesday, 28 April 2009, 14:02 GMT
Dan: I want to close this as not a makepkg problem now that there are bug reports open to add a check in namcap and for major offeding packages. Are you fine with that decision?

Loading...