RFC: new mock: strategy, selinux, etc.

[Axel Thimm]

On Thu, Jan 04, 2007 at 03:11:23PM -0600, Clark Williams wrote:
> 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.

Well, security is about not creating chances and about having several
lines of defenses. We shouldn't argue that any breach is a total
breach, so why bother. In this argumentation line, why bother dropping
root privileges at all?  (That's rhetorical - of course - just trying
to make my point).

The point is that you open the vulnerabilty to mock python code, any
other python code called by mock, as well as python itself. I think it
was easier to deal with the few lines of C code.

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

The helper C setuid wrapper would allow only certain operations,
i.e. any priviledge escalation is confined to the defined operations
in this helper.

This also reduces the amount of code to be reviewed wrt priviledge
escalation to just this wrapper. Now you have all of the python code
exposed to possible priviledge escalation issues.

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.
-- 
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/20070104/ccfbc99d/attachment.sig>