Discussion summary: Mock security

[Jeremy Katz]

David Smith wrote:
> On Tue, 2006-06-06 at 15:50 -0500, Michael_E_Brown at Dell.com 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.

> 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?

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.

>> 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 <williams at redhat.com> 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?

Jeremy