Mock and consolehelper

Michael E Brown Michael_E_Brown at dell.com
Wed Dec 19 15:24:49 UTC 2007


On Wed, Dec 19, 2007 at 07:19:33AM +0000, Kevin Kofler wrote:
> I have noticed that mock in Rawhide has been changed to drop the SUID helper, 
> instead consolehelper is used to run the entire mock as root. IMHO, this is a 
> regression:
> * It now means you have to know the root password to run mock. Before, it was 
> possible to give out mock access and only that simply by making the user a 
> member of the mockbuild group. Now the only way to do that is to allow running 
> all of mock as root, which probably opens up several ways to get full root 
> access from there.

Mock in rawhide is configured by default to run exactly like mock 0.8 in
F7/F8, ie. if you are in the 'mock' group you can run it by default.

Using consolehelper we now have the additional enhancement that people
not in the 'mock' group can run mock if they know the root password,
just like all of the other utilities that use consolehelper.

> * It means mock has to be run interactively. What are the implications of this 
> on the builders? Will they have to install all of mock SUID root, or set up 
> consolehelper in a way which effectively does the same?

Untrue.

> * It reduces security, as instead of a small helper doing only a few controlled 
> operations, you now run all of mock as root. Sure, it's Python, so buffer 
> overflows probably can't happen, but still, trigger any bug in mock with a 
> trojaned SRPM and you have root.

A small amount of research before we go off the deep end, please?

Mock has two main security concerns: 1) is it safe to let untrusted
users run mock, and 2) is it safe for a trusted user to compile
untrusted code using mock. As a project, the mock development team has
stated that (1) is not a current goal for the project, and that we would
strive to achieve (2), but there are several known holes that make 2
difficult to acheive.

Mock is already KNOWN TO BE UNSAFE TO RUN BY UNTRUSTED USERS, and
this has been stated time and time again.

If you run a shell server for a college, dont give those users access to
mock. There are *many* paths by which an untrusted user could easily
elevate their privileges. It is not a goal of mock to be runnable by
untrusted users. This is why access to mock is protected by the 'mock'
group or knowledge of the root password (in rawhide).

Even considering the above, we have taken steps inside the source to
minimize the privileges as much as possible. We drop privs before
copying the srpm and before setting up output logs. We drop privs for
the actual rpm build. This should provide a high (but not impregnable)
degree of protection for trusted users compiling untrusted code.

The new design (present in mock 0.8 and higher). Actually allows us much
finer access control, more auditable, easier to program, and numerous
other benefits as compared to the old mock <= 0.7 codebase.

--
Michael




More information about the fedora-devel-list mailing list