Implement a way to ensure build artifacts integrity after the %build, and during post-build phases like %check

[carlosrodfern]

After the build artifacts are created, it would be ideal to somehow make them immutable during the test in the %check. The goal is to protect their integrity.

This idea came from the Fedora devel discussion about how to build defense mechanisms against xz kind of backdoors.

Ideas of how to implement it:

Zbyszek:

If we wanted to pursue that, I'd suggest the following:
remount $RPM_BUILD_ROOT read-only for the %check phase
(or maybe overmount it with a writable overlayfs that is thrown
away after %check finishes, and warn if any modifications were made.)
%check is executed after %install, so everything should be in place
before %check, and %check may be skipped, so no modifications to
installed files should be done in %check.

Considering possible implemention details, machinectl has 'bind' and
'bind --read-only' that might be useful here. But mock uses
systemd-nspawn in a way that does register the container with machined.
So maybe it'd be more reasonable to just execute a mount command directly
from mock.

This is independent of the test system and does not require splitting
of the test sources.

Neal Gompa:

Another thing to consider is making RPM unshare each build phase like
it can for scriptlets now at install time1.

Sandboxing and limiting in rpmbuild itself like we can with rpm can
also help with this. I believe moss2' boulder tool does this.

[Conan-Kudo]

Yeah, it would be interesting for sure.

[xsuchy]

rpm-software-management/mock#1352

[carlosrodfern]

Is this project the right place to put this discussion and make an issue? Should it be mock instead?

This discussion could be used to see first how to implement this best. The overlayfs seems like a tempting way of doing it.

[carlosrodfern]

Another option can be as simple as backing up the entire directory prior to %check and use the CoW feature in xfs to optimize the operation. Then, restore it. It may actually be a lot simpler, and would require less permissions. It is basically the cp -ar --reflink=always ... (or rsync? which is supposed to be sporting CoW too)

Perhaps, this can be implemented with a macro to start getting something going: %state_backup, %state_restore, or something like that.

[pmatilai]

We've been entertaining ideas to this direction before the xz incident, eg #2985 (for read-only source) and #2989. Read-only buildroot would be a logical extension of this. Some of these things are stepping into "mock territory", but then people still do run rpmbuild through other means as well, including directly. And extra layer of protection rarely hurts.

[pmatilai]

Opened #3010 as well.

[xsuchy]

When you run rpmbuild directly I would argue that you do not care about security already :) I guess it will be hard for rpmbuild to handle remounts for you. While it is no brainer for Mock.
What mock will need to have in rpm implemented is:

1. rpmbuild -ba --nocheck foo.spec # this already exists
2. rpmbuild -bC --short-circuit # C as check, i.e. short circuit directly to %check section and not running anything else.

Between these two steps, Mock can fetch results and remount the filesystem.

[pmatilai]

That mock does something is not a reason to not improve rpmbuild security and package/packaging sanity enforcement. A test-suite modifying what gets packaged is simply horribly wrong, even if it's by accident. If we can catch that, then we should. That's a no-brainer to me.

[mikhirev]

My comment in #3010 is relevant for this issue too.