Bug 1642844

Summary: Please make pm request safe for fedora packagers
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: mockAssignee: Miroslav Suchý <msuchy>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jdisnard, jkeating, mebrown, mizdebsk, msuchy, praiskup, williams
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-19 18:14:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1641187, 1641191    

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 
  https://github.com/rpm-software-management/rpm/issues/104
which make this (and several others) issues obsoletes.

In fact, I find 
  https://github.com/rpm-software-management/rpm/issues/104#issuecomment-433024163
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
https://github.com/rpm-software-management/rpm/issues/104 

Last time
https://github.com/rpm-software-management/rpm/issues/104 
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