RFC: new mock: strategy, selinux, etc.

[Mike McLean]

Axel Thimm wrote:
> Check out for example CVE-2006-1542 and CVE-2006-4980.

The first points out that CWD is a possible malicious input. If we treat 
that data as untrusted, then there are ways we could address such a 
python bug. For the second, there are patches for python that address 
it, and it appears the major vendors took notice..

But of course, your point was not so much these particular issues as it 
was to demonstrate that python has suffered buffer overflows. The fact 
is that mock's basic model requires that python code be executed as 
root. Even if mock itself were written entirely in C (not that I'm 
suggesting this), we must run /yum/ as root. To get around that, you'd 
have to either not use yum or use a substantially different yum, both of 
which are really far from where we are now. To me, such an approach 
would be a new project altogether.

Exploits in the python interpreter are going to affect much more than 
mock. There are plenty of people out there using python in ways (as root 
or not) where exploits matter. As such, I think it is reasonable to 
expect that significant python exploits will be dealt with in a 
reasonable time frame by vendors. Also, a CVE search shows very few 
exploits that come from the python interpreter itself. In fact, you 
pretty much listed them all. Most of the rest come from the code written 
in python. This is something we can control at least.

> Anything that mock takes as an input from command line to submitted
> srpms/spec files. One of the cve's was triggered by specially crafted
> UTF-32, next exploit could be with UTF-8 found in specfiles. If you
> run with possible root priviledge elevation capabilities all the time
> anything mock calls directly or indirectly becomes vulnerable, be it
> cpython itself or a python module used by mock.

Such a vulnerability could just as well affect yum, which mock has to 
run as root. Given to relative code sizes and install bases, I would 
expect it is much more likely that yum would be the target of this sort 
of exploit, and there's not much we can do about that (without a massive 
change in direction).

So much of what mock does needs to be done as root that the mock-helper 
model creates a significant hurdle in clean design. The exec interface 
is slow and not very expressive. Also note the flaws I pointed out in my 
previous post.

If the group is really worried about these sorts of exploits, then I 
think we can work on accomplishing stronger privilege separation within 
the python code (I have some ideas on this that I can talk about later 
if folks are interested). I do not think that mock-helper is the right 
answer. Getting rid of it is a good first step.