Summary: | sys-apps/portage: insecure temporary location (CVE-2019-20384) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Michael Orlitzky <mjo> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | flow, hanno, kfm, nobrowser, sam, security |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 711148 |
Description
Michael Orlitzky
2019-08-19 01:54:03 UTC
Using an entirely unpredictable location would be problematic for current behavior of the ebuild(1) command since it can be invoked multiple times with the intention of operating on a predictable location. How about if we set secure permissions on the parent directory? We've already got a secure default PORTAGE_WORKDIR_MODE="0700" setting that applies to ${WORKDIR}, and we could apply it to the parent directory. (In reply to Zac Medico from comment #1) > > How about if we set secure permissions on the parent directory? We've > already got a secure default PORTAGE_WORKDIR_MODE="0700" setting that > applies to ${WORKDIR}, and we could apply it to the parent directory. I think that should work too. Couldn't the permissions of /var/tmp/portage simply be changed to deny all access to 'other' (chmod o-rwx)? This would deny access of arbitrary accounts to anything inside /var/tmp/portage. The would limit access to the portage user and the portage group, which is generally much more tightly controlled and 'trusted'. (In reply to Daniel Robbins from comment #3) > Couldn't the permissions of /var/tmp/portage simply be changed to deny all > access to 'other' (chmod o-rwx)? This would deny access of arbitrary > accounts to anything inside /var/tmp/portage. > > The would limit access to the portage user and the portage group, which is > generally much more tightly controlled and 'trusted'. Sure, that will give similar protection to the PORTAGE_WORKDIR_MODE approach from comment #1. I can't think of a reason not to apply PORTAGE_WORKDIR_MODE to PORTAGE_TMPDIR. (In reply to Zac Medico from comment #4) > (In reply to Daniel Robbins from comment #3) > > Couldn't the permissions of /var/tmp/portage simply be changed to deny all > > access to 'other' (chmod o-rwx)? This would deny access of arbitrary > > accounts to anything inside /var/tmp/portage. > > > > The would limit access to the portage user and the portage group, which is > > generally much more tightly controlled and 'trusted'. > > Sure, that will give similar protection to the PORTAGE_WORKDIR_MODE approach > from comment #1. I can't think of a reason not to apply PORTAGE_WORKDIR_MODE > to PORTAGE_TMPDIR. Actually, the default PORTAGE_WORKDIR_MODE="0700" setting is a little too restrictive for PORTAGE_TMPDIR, since normally this directory is writable by trusted users in the portage group. This patch will apply PORTAGE_WORKDIR_MODE to the PORTAGE_BUILDDIR parent directory, as suggested in comment #1: https://archives.gentoo.org/gentoo-portage-dev/message/4aed84c475a00594be4d53ef94643220 https://github.com/gentoo/portage/pull/533 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=ef8c21e59953aa5fdd153f19b7bf04356e2164fe commit ef8c21e59953aa5fdd153f19b7bf04356e2164fe Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-03-15 00:01:25 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-03-15 00:42:43 +0000 _prepare_workdir: apply PORTAGE_WORKDIR_MODE to PORTAGE_BUILDDIR (bug 692492) Apply secure PORTAGE_WORKDIR_MODE permissions to PORTAGE_BUILDDIR, since the child directory ${D} and its children may have vulnerable permissions as reported in bug 692492. Bug: https://bugs.gentoo.org/692492 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/package/ebuild/prepare_build_dirs.py | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=729dc030f6b318f84ca6336c7bd7dddaa7e48040 commit 729dc030f6b318f84ca6336c7bd7dddaa7e48040 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-03-15 01:23:23 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-03-15 01:29:25 +0000 sys-apps/portage: Bump to version 2.3.94 #692492 secure ebuild ${D} permissions #710444 omit zstd --long=31 for decompress on 32-bit arch #712298 respect emerge --deep=<depth> with --update Bug: https://bugs.gentoo.org/711148 Bug: https://bugs.gentoo.org/692492 Bug: https://bugs.gentoo.org/710444 Bug: https://bugs.gentoo.org/712298 Package-Manager: Portage-2.3.94, Repoman-2.3.20 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.94.ebuild | 271 +++++++++++++++++++++++++++++++++ 2 files changed, 272 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7f03ec4a46055a75eb13bf5fad85cf451822f589 commit 7f03ec4a46055a75eb13bf5fad85cf451822f589 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-05-25 00:43:07 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-05-25 00:43:23 +0000 sys-apps/portage: Remove vulnerable 2.3.89-r3 for bug 692492 Bug: https://bugs.gentoo.org/692492 Package-Manager: Portage-2.3.100, Repoman-2.3.22 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 - sys-apps/portage/portage-2.3.89-r3.ebuild | 271 ------------------------------ 2 files changed, 272 deletions(-) |