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