When you're creating base.tgz, chroot's /tmp is accessible to all local
users. Malicious local user could put arbitrary files there, and
pbuilder will pack them into base.tgz.

Is this really an issue considering that /tmp and a bunch of other
directories are usually world-writable?

Coupled with the fact that .deb packages are just .ar archives, which
preserve permissions of their members. After `debootstrap` begins its
execution, APT unpacks packages in the chroot, with permissions and
layout of the directories preserved.

The attached patch removes, during the recreation of base tgz,
all files from /tmp and /var/tmp (which is also world-writable).

It is made for the git version at salsa.debian.org but can also be applied
to the current (0.231) version as-is.

I have also modified a comment during the creation of BUILDDIR to alert for
the possibility of a user who keeps (still) in his/her configuration
/tmp/buildd
as the build directory.

It is not essential to the issue (only the tar command is), but I thought
it would be nice to have also. I can send a modified version of the patch,
if deemed necessary.

Cheers,
Georgios

Hi Georgios,

why not just ensure the parent directory of the chroot is not
traversable for just any normal user?

That would allow preserving /tmp/buildd as build place as well
as retaining stuff under /run which packages create and which
is, in practice, often needed for chroots where initscripts are
not run.

In addition, I often do use the access to the /tmp in the chroot
for debugging and bootstrapping, so maybe create a new system
group, chown 0:_pbuilder /var/cache/pbuilder/build; chmod 0750
that directory, and good is? (Untested.)

Then, I could add my user to that group and continue doing so.

bye,
//mirabilos

Hi Thorsten,

Limiting access to the expanded chroot is something that can be done.

I currently use a `build' group and have {mode 750, ug root:build}  the
build directory,
were the base tgzs are unpacked as subdirectories, and {mode 2775, ug
root:build}
the result directory, so that pdebuild-internal can copy back resulting
debs.

`build' group members are the developers that can use pbuilder. This is a
separate group
than the one that has sudo rights to run pbuilder (though both have the
same members);
its sole role is to allow write access to the result directory and read
access to the build
directory.

I made this setup recently and maybe it needs some tuning (probably mode 775
for the result directory is enough), but so far packages build successfully
with it.

However, this solution requires the creation of a system group during
pbuilder's installation
and setting permissions to the associated directories. Also whoever uses a
custom directory
setup should afterwards set the above permissions accordingly.

/tmp/buildd is already preserved by the compatibility symlink code inside
pbuilder, in the sense
that it is there after the base tgz unpacking. Even if the compatibility
code is removed, one can
set BUILDDIR=/tmp/buildd in pbuilderrc and have it there, as long as
BUILDDIR is always created
during unpacking. That's why I have shipped the patch with the modified
comments at that point.

Even if a choice is made for pbuilder to support limiting access to the
expanded chroot,
I believe that chroot's temporary directories should be cleaned before
creating the base tgz.
Other things also go there (hookdir, pbuildersatisfydepends package, etc.)
and, since by design
these directories are for temporary stuff, persistence should not be
anticipated.

Cheers,
Georgios

Στις Σάβ 27 Απρ 2024 στις 5:10 μ.μ., ο/η Thorsten Glaser <tg@mirbsd.de>
έγραψε: