RFC: new mock: strategy, selinux, etc.

[Clark Williams]

-----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-----