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