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