Design for use with linux-user-chroot

[cgwalters]

A security issue today with RPM-based buildsystems is that while it's common for the actual compilation process (make or whatever) to run as non-root, the buildroot creation still requires root.

I maintain: https://git.gnome.org/browse/linux-user-chroot/tree/README?id=1ab0cc3bc401c8e5578dd1da05aed502544e5183
which is intended to address this - and works successfully for the GNOME Continuous buildsystem.
However, that isn't using RPM.

I briefly looked at what it would take to use linux-user-chroot with RPM. This would mean not having the primary process call chroot() directly, but instead only do chroot /path/to/installroot /path/to/script when calling out to %post scripts - and that code path could then optionally use linux-user-chroot instead of plain chroot.

However, RPM currently relies on the chroot() system call to affect where it places files - so it would have to learn to either prepend the installroot when writing out content, or use openat() and friends with a directory fd for the install root.

Another subtle but important one: RPM presently relies on chroot() affecting NSS lookups pulling uid/gid mappings from the target /etc/passwd and such. See: http://lists.rpm.org/pipermail/rpm-maint/2014-January/003656.html This one would be annoying to fix - may need custom NSS code.

[cgwalters]

Also worth linking to https://github.com/wrpseudo/pseudo which is a maintained alternative approach for non-root RPM operation.

[kad]

There is also http://proot.me/ that uses ptrace instead of LD_PRELOAD (like pseudo or fakeroot).

[ffesti]

On 07/23/2015 10:07 PM, Colin Walters wrote:

A security issue today with RPM-based buildsystems is that while it's
common for the actual compilation process (|make| or whatever) to run as
non-root, the buildroot creation still requires root.

I maintain:
https://git.gnome.org/browse/linux-user-chroot/tree/README?id=1ab0cc3bc401c8e5578dd1da05aed502544e5183
which is intended to address this - and works successfully for the GNOME
Continuous buildsystem.
However, that isn't using RPM.

I briefly looked at what it would take to use |linux-user-chroot| with
RPM. This would mean not having the primary process call |chroot()|
directly, but instead only do |chroot /path/to/installroot
/path/to/script| when calling out to |%post| scripts - and that code
path could then optionally use |linux-user-chroot| instead of plain
|chroot|.

However, RPM currently relies on the |chroot()| system call to affect
where it places files - so it would have to learn to either prepend the
installroot when writing out content, or use |openat()| and friends with
a directory fd for the install root.

Another subtle but important one: RPM presently relies on |chroot()|
affecting NSS lookups pulling uid/gid mappings from the target
|/etc/passwd| and such. See:
http://lists.rpm.org/pipermail/rpm-maint/2014-January/003656.html This
one would be annoying to fix - may need custom NSS code.

While you caught some of the uses of chroot this list is far from
complete. Another one would be access to the rpmdb (which is done by
libdb and though not 100% under our control). As the index dbs and the
environment files may be opened or even create during normal operation
it also take doesn't take messing around with chroot lightly.

Florian

—
Reply to this email directly or view it on GitHub
#8.

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters

[ffesti]

Moved issue to http://rpm.org/ticket/896 as we are closing the github issue tracker for now.