On Wed, 2006-06-07 at 11:13 -0400, Jeremy Katz wrote:
David Smith wrote:
> On Tue, 2006-06-06 at 15:50 -0500, Michael_E_Brown(a)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.
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 <williams(a)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?
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