tux root # emerge -uDvf world Tasks: 102 total, 2 running, 99 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0% us, 0.3% sy, 0.0% ni, 97.4% id, 1.0% wa, 0.3% hi, 0.0% si Mem: 904768k total, 848208k used, 56560k free, 129080k buffers Swap: 610460k total, 85948k used, 524512k free, 361756k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12930 root 15 0 173m 39m 133m S 0.7 4.5 6:34.22 X 1042 root 15 0 5964 1480 5732 S 0.7 0.2 0:00.03 wget 1043 root 16 0 1924 988 1708 R 0.3 0.1 0:00.01 top [...] Reproducible: Always Steps to Reproduce: 1. tux root # emerge -uDvf world 2. top (in other window) Tasks: 102 total, 2 running, 99 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0% us, 0.3% sy, 0.0% ni, 97.4% id, 1.0% wa, 0.3% hi, 0.0% si Mem: 904768k total, 848208k used, 56560k free, 129080k buffers Swap: 610460k total, 85948k used, 524512k free, 361756k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12930 root 15 0 173m 39m 133m S 0.7 4.5 6:34.22 X 1042 root 15 0 5964 1480 5732 S 0.7 0.2 0:00.03 wget 1043 root 16 0 1924 988 1708 R 0.3 0.1 0:00.01 top [...] Actual Results: 1042 root 15 0 5964 1480 5732 S 0.7 0.2 0:00.03 wget Expected Results: IMHO wget should run as portage user (otherwise we are vulnerable if wget is vulnerable) as emerge does with userpriv when compiling: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15784 portage 25 0 31844 25m 9016 R 99.0 2.9 0:00.65 cc1plus 1 root 16 0 1344 436 1188 S 0.0 0.0 0:00.49 init This can be done, since distfiles directory is writable by portage group: tux root # ls -ld /usr/portage/distfiles/ drwxrwsr-x 4 root portage 45056 Dec 18 01:17 /usr/portage/distfiles/ Maybe I missed a feature variable that can be set to do this? FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict userpriv userpriv_fakeroot usersandbox" bash-2.05b$ emerge info Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r9 i686) ================================================================= System uname: 2.6.9-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict userpriv userpriv_fakeroot usersandbox" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa apm arts artswrappersuid avi berkdb bitmap-fonts cdparanoia cdr crypt cups divx4linux doc dvd dvdr dvdread emacs encode esd f77 fam ffmpeg flac foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile imagemagick imap imlib jack java jpeg jpeg2k junit kde ldap libg++ libwww live mad mikmod mmx motif mozcalendar mozdevelop mozilla mozsvg mpeg mysql mythtv nas ncurses nls objc oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline ruby scanner sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype unicode usb v4l v4l2 wmf x86 xml xml2 xmms xprint xv xvid zlib video_cards_radeon linguas_en linguas_en_US linguas_de
cc security if you'd like, but this isn't a security hole so reassigning. The privs *should* be decreased however, but no point in cluttering their box up.
> cc security if you'd like, but this isn't a security hole so reassigning. It's not a direct security hole, but a security enhancement. However I shortly read that wget is vulnerable, so it might be an important enhancement: (german) http://www.heise.de/security/news/meldung/54171 http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0106.html Bug#: 74008 So this report shows a weakness that could perhaps be exploited. That's why I assigned it to Gentoo Security. To provide a better in-depth protection, it would perhaps make even more sense to execute FETCHCOMMAND as a completely other user (not portage, e.g. some new user to be created, I call him "fetchuser"), who is _not_ even in the portage group. FETCHCOMMAND then downloads the file to a temporary location and portage user copies it to distfiles directory. Rationale: if wget is vulnerable, the only user affected would then be "fetchuser". This user could only modify one freshly downloaded file. When we then try to emerge the package the modification would (hopefully) be detected. If root is affected (current situation), we are lost. If portage user is affected however, new installations might be affected. If "fetchuser" is affected, no major problems should arise (reboot or kill all "fetchuser" processes by hand, select another server to download your distfiles from, and go along?)
I agree this is not a vulnerability per se, but it's true it makes the impact of any other vulnerability (like the current wget path traversal issues) much higher. We'll follow this from the Cc: and encourage the portage team to fix it :) -- Koon (Gentoo Linux Security Team)
Wasn't aware of the wget bug, although the potential for the fetcher to be 'special' doesn't surprise me. Offhand, enabling userpriv for it -can- be flipped on pretty easily, although a lot of the access checks will need to be checked over/rewritten. One thing to note, that just drops the fetcher down to the portage user- they still can do a fair amount of damage. Thoughts about flipping the sandbox on? Well aware the sandbox isn't a full security solution, but it is an extra annoyance/hurdle that must be jumped. Alternative to protect portage files (which is needed if you consider what portage does), is a seperate fetcher user I spose... or use selinux + the portage_fetch context... :)
Reminder: using portage-2.0.51-r15 it still runs as root.
You need to settle down about this. It's not going to change halfway through a stable release. If you are really worried about it for your own use, just write a small wrapper script that drops privileges.
I'm not worried about my own security, since there is an easy workaround: I use a non-root user in portage group to fetch the files and only install them as root.
This also forces lower security when /usr/portage/distfiles is NFS mounted, because root is aliased to the nobody user by default so can't write there. Thus, either you have to remap root to a privileged user or allow root to write to the NFS mount.
Is released with FEATURES="userpriv" enabling this in 2.0.51.22 but will change to FEATURES="userfetch" in 2.0.51.22-r1.
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
