#563398 SECURITY: Host user 1234 can tamper with build chroot

#563398#5
Date:
2007-06-27 08:34:11 UTC
From:
To:
Hi,

As discussed on the boat under DebConf, here's a patch to enable ccache
support in pbuilder. I've only tested it lightly, but it seems to work
well.

#563398#10
Date:
2007-06-27 18:10:39 UTC
From:
To:
it ?

FWIW, the simple setup that just works(tm):
    export CCACHE_DIR="/var/cache/pbuilder/ccache"
    export PATH="/usr/lib/ccache:${PATH}"
    EXTRAPACKAGES=ccache
    BINDMOUNTS="${CCACHE_DIR}"

BTW, why not use CCACHE_DIR instead of CCACHE_LOCATION ?

Mike

#563398#15
Date:
2007-06-27 20:52:06 UTC
From:
To:
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.

Feel free to change such aspects. :-)

/* Steinar */

#563398#20
Date:
2007-06-27 23:12:38 UTC
From:
To:
Hi,

I don't think that's too much of a problem if the way ccache works is
what I think it does.  Looking at Steiner's patch, it's rather too
big. Why not just provide the configuration file, and make a shorthand
option for the configuration?

I think it'd be better to follow existing documentation and name it
accordingly.

http://pbuilder.alioth.debian.org/#ccache


regards,
	junichi

#563398#25
Date:
2007-06-27 23:24:24 UTC
From:
To:
Could you outline your assumptions, please?

Well, if you change the {save,restore}_ccache to using bind mounts instead,
the patch _is_ almost just that. So I guess we agree :-)

/* Steinar */

#563398#30
Date:
2007-06-28 00:00:23 UTC
From:
To:
Hi,

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.

There's a big difference between using already-existing --bindmounts
feature through configuration file and adding a new function.


regards,
	junichi

#563398#35
Date:
2010-01-02 16:16:38 UTC
From:
To:
clone 430765 -1
retitle -1 SECURITY: Host user 1234 can tamper with build chroot
tag -1 + security
stop

 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.

    Thanks,