On Wed, 2006-06-07 at 11:13 -0400, Jeremy Katz wrote: > David Smith wrote: > > On Tue, 2006-06-06 at 15:50 -0500, [EMAIL PROTECTED] wrote: > >> After looking closely at the mock-helper source, I have identified > >> several problematic areas, listed below. I do not believe, given the > >> current state of mock-helper, that we should endorse the idea of > >> allowing untrusted users access to the 'mock' group. We should very > >> prominently label mock as giving, essentially, root access to each user > >> you allow to run it. I believe the wiki, the help text of "mock -h", the > >> mock README, and the mock man page should all be updated with this > >> information. > > > > ... stuff deleted ... > > > > If you implemented all your proposed solutions, do you think that > > warning could be removed? Do you think that mock would be secure at > > that point? > > It sounds like Michael did a pretty full investigation. And things at > least initially weren't bad off in this respect.
I don't want to lead anybody astray here. I am not a security expert, so there may well be other things here that I am missing. I just pointed out the ones that were obvious to me. > > > If the answer is no, how much effort do we want to spend here if at some > > point we have to trust the users in the "mock" group anyway? Given the current state of mock-helper, I would say a different design is called for, one where 'untrusted' user cannot pass any data down to a trusted process, or as a last resort, all data that is passed is subject to rigorous validation. > We really want it to be pretty secure, though -- otherwise, it's a risk > for build farms and a future where we might try to have shell servers > available for all arches for people to test and debug builds. > That is the thinking behind my audit. > >> Problem area: do_chroot() > >> passes unchecked user data to chroot command. User can easily > >> get a shell, and, for example, create device nodes. > [snip] > > In our case, we're using mock to cross-build RPMs. Here's how my co- > > worker Clark Williams <[EMAIL PROTECTED]> described it a few months > > ago when he added the chroot command: > > What if, instead, it chrooted + changed to the mockbuild user? Would > that break your usage case? Since the mockbuild user in the chroot == current user id non-chroot, this should preclude some problems, the problem is that many operations will not be able to be done by current user id due to permissions. The two suggestions I have seen to fix the architecture here are: A) A daemon that runs as root. It accepts minimal 'commands' from untrusted user and uses those commands to build the chroot. B) Same idea as above, but as a SUID program instead of daemon. the problem with (B) is that it will be a C program, where (A) can be a python executable. I think we all know which one is easier to maintain. The problem with the implementation of this solution is that it involves a pretty hefty rewrite of large portions of code, and then re-testing. It is only worth this effort if somebody steps forward and says they actually need this level of security. -- Michael -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
