RFC: new mock: strategy, selinux, etc.

Axel Thimm Axel.Thimm at ATrpms.net
Thu Jan 4 20:06:01 UTC 2007


On Thu, Jan 04, 2007 at 01:13:25PM -0600, Clark Williams wrote:
> Axel Thimm wrote:
> > On Thu, Jan 04, 2007 at 10:37:03AM -0600, Clark Williams wrote:
> >> New mock will no longer use mock-helper. When it needs to do something
> >> that requires root privileges, it will elevate it's privilege level to
> >> root (using os.setreuid()), execute the command and then drop privileges
> >> back to the normal user.
> > 
> > But isn't this a security regression towards the previous model?
> > Previously all elevation procedures were confined and well
> > controlled.
> > 
> 
> 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.

> 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?
-- 
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/7f4c19d8/attachment.sig>


More information about the Fedora-buildsys-list mailing list