Bug#430765: [Pbuilder-maint] Bug#430765: please add ccache support

[Mike Hommey]

On Sat, Jan 02, 2010 at 05:16:38PM +0100, Loïc Minier wrote:
> clone 430765 -1
> retitle -1 SECURITY: Host user 1234 can tamper with build chroot
> tag -1 + security
> stop
> 
> On Thu, Jun 28, 2007, Junichi Uekawa wrote:
> > > >> The permissions get all wrong. I initially tried bind-mounting, but suddenly
> > > >> a random user from the outside can fiddle with your ccache. That is not a
> > > >> good thing.
> > > > I don't think that's too much of a problem if the way ccache works is
> > > > what I think it does.
> > > 
> > > Could you outline your assumptions, please?
> > 
> > ccache is supposed to do the right thing even when ccache data is
> > shared inside/outside of chroot, right? Users can fiddle with your
> > ccache and you should not be affected.
> 
>  I don't think ccache can detect this case; I think what Steinar is
>  saying is that e.g. /var/cache/pbuilder/ccache/**/* files will be owned
>  by the user from within the chroot used to build packages, typically
>  uid 1234, but this user might be a real (potentially malicious) user
>  outside of the chroot.  This 1234 user on the host could change the
>  compiled data so that the next build using the ccache with the same
>  source would pick up a modified (and malicious) version.
> 
>  I agree it's an issue, and I think pbuilder should create an user +
>  group on the host, and use the same uids in the chroots (e.g. "getent
>  passwd >$CHROOT/etc/passwd").
> 
>  I think this is not a new issue though: the build also runs as guest
>  uid 1234 and a malicious host user 1234 could just as well write to:
>  /var/cache/pbuilder/build/<build-id>/tmp/buildd/<source-package-version>/
>  (i.e. to the build tree).
> 
> 
>  I just pushed a ccache support patch to pbuilder git; I'm happy to hear
>  feedback on this patch.

Shouldn't pbuilder try to use the original user uid ? I, for one, set
BUILDUSERID to my own uid...

Cheers,

Mike