RFC: new mock: strategy, selinux, etc.

[Mike McLean]

Axel Thimm wrote:
> But isn't this a security regression towards the previous model?
> Previously all elevation procedures were confined and well
> controlled.

I'm sorry for replying so late on this thread. I'd like to respond to 
some of the criticisms of the new model and explain some of the reasons 
I had for suggesting it.

The mock-helper model is flawed because mock-helper does not have enough 
context to make informed security decisions. Any user in the mock group 
can run mock-helper directly and get it to perform any action that it 
would allow mock to do. While these actions are limited, they are not so 
limited that you can't do anything dangerous. In order to give 
mock-helper enough context to really know what it should allow, you 
would have to move large portions of the logic from mock.py to 
mock-helper, which would negate all the arguments about the size and 
complexity of the privileged code (note that mock-helper already 
accounts for about 30% of the lines of code).

The current mock-helper security is swiss cheese anyway. A user in the 
mock group can become root inside the chroot with a simple mock or 
mock-helper command. As root, it is possible to escape from the chroot. 
Game Over.

Suppose that we were to modify mock.py so that the shell and chroot 
commands run as a non-root user. Unfortunately mock-helper would still 
have to allow chroot as root, since mock.py needs this functionality 
itself. Users would still be able to run mock-helper directly. Even if 
we were able to plug that hole, the user would still be able to use 
mock-helper to install a suid binary into a chroot and then simply 
execute it.

With the new model, we can at least address aspects of this because 
users in the mock group cannot access arbitrary mock-helper features. 
They can only take the actions that mock offers through the command 
line. Mock has all the context it needs to make such decisions. It knows 
what it should be doing. If we don't allow users to point to arbitrary 
mock configs, they will not be able to install arbitrary suid code in 
the chroots. If we don't allow users to chroot as root, they won't be 
able to get around it by calling mock-helper.

> 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 not sure what type of exploit you're worried about here. As a python 
app, mock should be very resistant to buffer overflow exploits. 
Furthermore I'm not sure what interface the exploit would come through 
.. the command line?

Clark's plan for dropping privilege and only elevating for key 
operations is a good one and will provide some protection against coding 
  errors doing too much damage.

I don't mean to say that the new model will be perfect. I think we will 
always need to caution admins to only add trusted users to the mock 
group. However, I think mock will be at least as secure as before and 
much more maintainable.