-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. >> >> 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. >
I've used fakeroot/fakechroot in the past, but ran into RPM problems (where RPM wanted to take a lock that required root). I'm not positive, but I think that particular RPM problem has been fixed. 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: 1. Simplified uid/gid scheme so that multiple users can work properly 2. Running in our own namespace. 3. Proper SELinux integration What I'd like for #1 is for the process to setgid:mock once the user has been verified. At that point every file created has gid mock and so there shouldn't be any ownership conflicts in chroots. As far as I can tell the only way to setgid group is to run from a setgid program, so that means the launcher. I've seen two ways we can do namespaces. The first is a couple of patches that modify mock-helper. The other is to do it in the launcher. I'd prefer the launcher since it's less code than the patches to mock-helper. If we keep the launcher *and* mock-helper, and have the launcher do a setreuid(getuid(), getuid()) before exec'ing python, I /think/ that means we lose the ability to switch back to root (the euid). I'll need to go dig into my copy of Advanced Programming in the Unix Environment and probably write a test case to be sure. 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? If so, we can get the three above things in, push it to rawhide and then discuss moving to fakeroot/fakechroot. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnqE0Hyuj/+TTEp0RAqBAAKDfFdrUgnm2Bpf0kRQ/xnVZkLnHWwCgwx5w L8JqelaoriBUY+HDS6IusO8= =EOJa -----END PGP SIGNATURE----- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
