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. * 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? * 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.
Kevin Kofler
On Wed, 2007-12-19 at 07:19 +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.
You can configure access to mock through the /etc/pam.d/mock file and it currently already should allow to non-interactive use by users in group mock. There is:
auth sufficient pam_rootok.so auth sufficient pam_succeed_if.so user ingroup mock use_uid quiet
- 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?
- 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.
mock could still drop priviledges - change to mock user or whatever as soon as it doesn't need to be root anymore.
On Wednesday 19 December 2007 08:19:33 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.
Older versions of mock already allow every user that is allowed to run it, i.e. is in the mockbuild group, to get root access:
$ mock shell init mock-chroot> chmod u+s /bin/bash mock-chroot> exit exit ending done $ /var/lib/mock/fedora-7-i386/root/bin/bash -p
Regards, Till
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
-
Kevin Kofler -
Michael E Brown -
Till Maas -
Tomas Mraz