On Fri, Jan 05, 2007 at 01:04:20PM -0600, Clark Williams wrote: > Axel Thimm wrote: > > On Fri, Jan 05, 2007 at 10:52:04AM -0600, Clark Williams wrote: > >> Axel Thimm wrote: > >>> In a nutshell: you now carry much more unlimited root power throughout > >>> all of mock's invocation cycle in comparison to a confined set of > >>> priviledges that the helper was giving. > >> Good point. I still think it's easier to audit python code than C code, > >> but you're talking 500 lines of C versus 1000 lines of python. So, I may > >> just reconsider this change.
> > How about a very radical approach: Removing the neccessity to have > > root priviledges at the first place anywhere. [...] The question > > is whether that is technically possible [...] I use > > fakechroot/fakeroot to maintain chroots as a simple user. I think > > that will work with eliminating the need for the chroot part in > > the mock helper as well. If we check the remaining parts in mock > > requiring root priviledges (perhaps just for mounting?) perhaps we > > can eliminate these, too, and end up with a pure non-root working > > mock. > I'm not adverse to trying it in the long run, but I don't really want to > try and put it in for the next release. I want to get three things > working for the next release: Indeed, I wasn't suggesting this as a short-term maneuvering. > So again I ask: if we modify the launcher to setgid:mock and to drop > root privilege after it's created the new namespace and before it exec's > python, keeping mock-helper for root access, will that satisfy your > security concerns for now? Yes, in that scenario it seems like the max possible damage is done by mock-group priviledges (if the helper itself doesn't come up with any issues), and the mock group cannot damage the host other than with resource draining, e.g. no further priviledge escalation. > If so, we can get the three above things in, push it to rawhide and > then discuss moving to fakeroot/fakechroot. -- Axel.Thimm at ATrpms.net
pgpzTjctb2wMP.pgp
Description: PGP signature
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
