Bug 1642844 - Please make pm request safe for fedora packagers
Summary: Please make pm request safe for fedora packagers
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1641187 1641191
TreeView+ depends on / blocked
Reported: 2018-10-25 08:11 UTC by Nicolas Mailhot
Modified: 2019-04-19 18:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-04-19 18:14:12 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Fedora Pagure fesco issue 2004 0 None None None 2018-10-25 08:11:51 UTC
Github rpm-software-management mock issues 224 0 None None None Never

Description Nicolas Mailhot 2018-10-25 08:11:52 UTC
In https://pagure.io/fesco/issue/2004 mizdebsk worries that enabling the pm request mock extension on Fedora build systems (copr and koji) would lead to evil, and that attackers could use it to convince mock to pass dangerous commands to dnf.

Please add a restricted secure mode to pm request where it can only be used to

 * install/upgrade packages to the mock chroot or container from the repositories configured in the *repo files
 * executing the corresponding scriptlets with the mock chroot or container

And that, no matter what parameters an attacker manages to get passed through the pm request socket

Regardless of what FESCO decides in the pagure ticket the same config is running on packager systems today, the mock on those systems is the first line of defense against compromised upstream sources, so it needs to be secured properly.

Comment 1 Miroslav Suchý 2018-10-25 09:03:51 UTC
1) when bootstrap is used, then the pm_request should [*] use DNF from the bootstrap chroot. Which should be safe.
[*] need to verify this claim in a code.

2) how I can restrict to only repos configured in the config? You can easily install rpm with repo file and then execute install and you will get a package from that new repo. 

I see no problem implementing "secure" mode, but this needs to be precisely defined on a low technical level.

Comment 2 Nicolas Mailhot 2018-10-25 09:25:59 UTC
From a security POW, I think the dnf mock uses should only honor the repo definitions in the mock config, and ignore any repo definition dropped in the buildroot.

At least I don't see why one would want it otherwise, both from a functional and security angle.

Comment 3 Nicolas Mailhot 2018-10-25 09:28:11 UTC
Basically you want the dnf in the chroot to use only repo defs configured within mock by the mock admin, and ignore any repo addition or redefinition done by the env in the chroot, via dnf cli flags, repo definition files, or anything else I forget here.

Comment 4 Pavel Raiskup 2018-10-25 11:22:33 UTC
(In reply to Miroslav Suchý from comment #1)
> 2) how I can restrict to only repos configured in the config? You can easily
> install rpm with repo file and then execute install and you will get a
> package from that new repo. 

AFAIK, `mock --install` doesn't use the repofiles installed inside the
chroot (only those repofiles inside {dnf,yum}.conf).

Comment 5 Pavel Raiskup 2018-10-25 11:23:33 UTC
> only those repofiles inside {dnf,yum}.conf

I mean, mock only uses **repositories** specified in {dnf,yum}.conf.

Comment 6 Miroslav Suchý 2018-10-26 00:25:34 UTC
To be honest - this and GH discussion shows that this feature would be very fragile and it can actually limit or break normal behaviour of mock.

I would rather focus on 
which make this (and several others) issues obsoletes.

In fact, I find 
very attractive.

Comment 7 Nicolas Mailhot 2018-10-26 08:16:15 UTC
Just to be clear: I will drop pm request as soon a
https://github.com/rpm-software-management/rpm/issues/104 lands in Fedora

(though I may be stuck with it on el7, which means is still needs security fixing)

Please do not give up on pm request before we have an ETA in

Last time
revived, there were lots of interesting comments, and then it all died out without any deployable solution.

Fascinating as those discussions are, my primary objective is to do packages in Fedora!

Comment 8 Miroslav Suchý 2019-04-19 18:14:12 UTC
Closing in favor of Dynamic Build Dependencies, which just landed in Mock

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