RFC: new mock: strategy, selinux, etc.

[Clark Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Axel Thimm wrote:
> On Thu, Jan 04, 2007 at 01:13:25PM -0600, Clark Williams wrote:
>> One of the first thing that the __init__() method for class Root does in
>> mock.py is to call self.drop() to lower the privilege level. Thereafter,
>> any command that new mock does as root is done via the do_elevated()
>> method of the Root class, and any time the actual python code needs root
>> access (e.g. the rpm library routines), it's bracketed by elevate() and
>> drop() calls. This makes it easy to audit how the commands are used and
>> in what context code is executed.
> 
> I understand the mechanism, but what if a security issue elsewhere in
> mock allows one to inject code and elevate privildeges? Until now any
> rogue mock takeover would only be able to do what the confined C
> helper program would allow, now everything is possible.
> 

I'm trying to figure out how someone would inject code into mock and not
already be root (which to me means Game Over). To successfully exploit
something, an attacker must cause some code to be loaded that either:

1. runs between an elevate and a drop
	or
2. does it's own os.setreuid(0, ...)

To do #2,  they would have to gain control of one of the 15 the files in
/usr/lib/python2.X/* that we import. I'm not sure how someone would be
able to gain control of a running instance of mock and be able to insert
code arbitrarily.

Please don't misunderstand me, I'm not dismissing your concerns, but I
don't really see how this is any less secure than what we had
previously. To me it's just a matter of where we focus our efforts in
making mock secure.

>> The main reason we wanted to get rid of mock-helper is that it was
>> non-trivial C code and the thought was to limit the amount of work
>> that's done at the C level. Yeah, I realize that it's easy to write bad
>> code in Python too, but it's harder to inadvertently set up a buffer
>> overflow situation in Python than in C.
> 
> But now you have several times more code that can lead to priviledge
> escalations compared to before - in fact it sounds like all of the
> python code including all used non-mock python modules could run
> setreuid or not?


It's the same amount of privilege escalations as before, just under the
control of the python code.

You might want to take a look at this list thread:

http://www.redhat.com/archives/fedora-buildsys-list/2006-June/msg00018.html

which is what prompted this change.

Clark


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFnW17Hyuj/+TTEp0RAtY/AJ4zC1IS20iQtOLlkav/DqlQGQg2mgCfQbkF
AmfG3awGJcGdXzp1yOZQQEA=
=DcHc
-----END PGP SIGNATURE-----