RFC: new mock: strategy, selinux, etc.

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-buildsys-list/attachments/20070105/58d2d7fd/attachment.sig>