RFC: new mock: strategy, selinux, etc.

[Axel Thimm]

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.
> 
> One of the reasons I liked moving to a setuid/setgid launcher was that
> we could move the process into the mock group and fix a bunch of chroot
> sharing problems with appropriate group permissions. Oh, and we actually
> kick off the python process in a separate namespace, which means we
> won't dirty up the mount table if for some reason we exit unexpectedly.
> 
> If we just made the launcher setgid:mock and kept mock-helper for
> rootiness things, would that still trigger your security alarms? Hmmm,
> now that I think about it, we probably have to be root to create a new
> namespace, so the launcher might have to stay setuid:root and drop
> privileges before exec'ing python.
> 
> Thoughts?

How about a very radical approach: Removing the neccessity to have
root priviledges at the first place anywhere. The benefits are clear
security-wise, and you get the added bonus that you can have people
install mock under their $HOME w/o being root on these system (imagine
students working on campus/lab PCs). One could even create a Fedora
SDK that runs on non-rpm Linux platforms - mock infiltrates everything
;)

The question is whether that is technically possible - for what I use
at ATrpms, an ancient bunch of shell scripts being the equivalent of
mock, 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 submitted fakeroot/fakechroot shortly before 2006 phased out, once
they are through one can start playing with them (I think fakechroot
is there, still waiting for fakeroot+dependency reviews to complete).

BTW the Debian/Ubuntu build systems make extensive use of
fakeroot/fakechroot for exactly the same scenarios.
-- 
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/2140cfc6/attachment.sig>