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.
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
