[darcs-users] suggestion: each push should identify its targe t repo internally

[Zack Brown]

Hi,

(Disclaimer: I'm not really clear on how darcs behaves currently with regards
to running programs automatically; these are some ideas of how it *might*
behave)

On Mon, Aug 18, 2003 at 10:17:40AM -0400, David Roundy wrote:
> On Fri, Aug 15, 2003 at 03:45:15PM +1000, BARBOUR Timothy wrote:
> > > From: David Roundy [mailto:droundy at abridgegame.org]:
> > > [...]  I'm not comfortable building infrastructure into darcs for
> > > dispatching patches patches to repos because unless you are rather
> > > careful (or only include your own key in allowed_keys), you could be
> > > opening up security holes in your system by running multiple pushable
> > > repos as the same user.  Anyone who has write access to a repo that
> > > runs the test on applied patches can run arbitrary code on your system.
> > 
> > It seems highly desirable to limit the security consequences by running
> > the test as a low-privileged user (similar to nobody).  If I understand
> > correctly, darcs check will use the patches in the repository to
> > re-create the current tree, then presumably run the test on it. Perhaps
> > it could be modified to re-create the current tree, then chown -R that to
> > the low-privileged user (darcs_test ?) and run the test as that
> > user. That probably does not eliminate the security risk, but should
> > reduce it a lot.
> 
> Hmmmm.  That does sound like a good idea.  The biggest problem being that
> I've never done anything like this before.  I'm not sure how to switch
> users, though, when darcs is not run as root.  I guess it must be doable,
> I'm just not sure how to do it...

I think a safer assumption is that if you run something at all, it's up to
you to know what you're running. The whole idea of having a test program run
automatically is inherently insecure, no matter what privileges or safeguards
you take. That doesn't mean it's a bad thing to do, but the focus shouldn't
be on making it safe. It really can't be done on normal systems. Yes,
theoretically its possible, but it should be trivial for the user to
control how much they expose themselves to that risk.

It's a cool feature to have hooks in darcs that allow events to happen during
push or apply. But these hooks should be generic. Some projects will want
to run compilation tests during any push, and say that anyone who doesn't
guarantee compilability will have their patch rejected.  Other projects will
have complete trust in all their members, and run something during the apply
process, perhaps to compile a public snapshot of something or other. Some
people will want to run things during the apply phase, but allow the remote
users to alter what will be run.  Others will want the remote users to have
no control over what runs.  Some projects may want to update a web page
whenever one person does a push but not other people. etc etc.

it's not up to darcs to provide all those features. All it has to do is
provide hooks that allow the repo owner to set up things to happen when
various events occur. There could be a hook for push, for apply, for record,
and really for every darcs command; and then the repo owner can specify a
program to run that is within the repository (modifiable by the remote users)
or outside the repository (protected from modification). It should even be
possible to have the code within the repo, but send out an alarm if anyone
actually *does* modify it, and then prevent itself from being run again
until a 'switch' is flipped by the repo owner or someone else with that
privilege.

In the above case, the security issue is only how to prevent users from
circumventing the various hook rules, to find ways of executing code that
they are theoretically not allowed to. That's a much better proposition
than trying to secure the code that is actually allowed to run. Once a darcs
hook has been set to do something, as long as it can't be hostilely made to
do something other than that, then security is not darcs' problem anymore,
but the repo owner's. If they say code should run under X circumstances,
and it runs, that's their problem.

Be well,
Zack

> 
> > For the truly paranoid, it might be desirable to be able to specify that
> > the test will be run inside a chroot or even a virtual machine (such as
> > user-mode linux).
> 
> Running inside a chroot would generally be tough, since the test usually
> will require dev tools, so the chroot wouldn't be very empty.
> -- 
> David Roundy
> http://www.abridgegame.org
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at abridgegame.org
> http://www.abridgegame.org/mailman/listinfo/darcs-users

-- 
Zack Brown