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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
