Bug 1283709 - Path traversal in `uniqueext`
Path traversal in `uniqueext`
Product: Fedora
Classification: Fedora
Component: mock (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Suchý
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-19 11:12 EST by Colin Walters
Modified: 2016-01-20 10:40 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-21 19:18:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Colin Walters 2015-11-19 11:12:37 EST
I know mock does not really claim to be "secure", but it's worth at least keeping track of these sorts of issues for two reasons:

 - To demonstrate criteria by which an actually secure build system should be judged
 - It's worth fixing these for reliabilty reasons

# mock -r epel-7-x86_64 --init --install strace --uniqueext=/../../../tmp/foo

will create a chroot outside of /var/lib/mock in /var/tmp/foo, and I can't see anything stopping one from just overwriting the host /.
Comment 1 Miroslav Suchý 2015-12-21 19:18:48 EST
I am not sure if this should be addressed. If your user is in 'mock' group, then you can root access anyway.
And if you provide incorrect path... well we provide gun, and you are shooting. If you want to shoot into your leg...
And btw, if you have selinux enabled, it should stop you from overwriting /.
Comment 2 Colin Walters 2016-01-20 10:40:32 EST
(In reply to Miroslav Suchý from comment #1)
> I am not sure if this should be addressed. If your user is in 'mock' group,
> then you can root access anyway.

Right.  But given that, I feel the `mock` group is a historical mistake, as there's an implication that it provides security where it doesn't.  If a program is effectively equivalent to a root shell, it would have been beetter to require use of `sudo`.  (One could find the uid to chown result files via `SUDO_UID` etc.)  It would drop a vast amount of complexity from mock.

I'm not arguing for making this change now though, it probably isn't worth doing.

For reference I am the developer of https://git.gnome.org/browse/linux-user-chroot which I do believe is secure, and that's the specific program that I'm comparing vs mock.

Note You need to log in before you can comment on or make changes to this bug.