[darcs-users] DARCS pushable repository security question

[David Roundy]

On Sat, Oct 18, 2003 at 01:08:02PM -0400, Sean E. Russell wrote:
> Is there a document that elucidates the statement from the darcs manual:
> 
> "When you set up a pushable repository, you are allowing anyone who has
> write access to that repository to run arbitrary code on your machine."
> 
> I'm curious as to whether this is strictly true, or whether it is an
> exaggerated statement intended to make people more aware of security
> issues.
> 
> In particular, are there known exploits of the darcs executable, or does
> the darcs push server actually execute arbitrary commands in the emailed
> patches?

It's somewhat exaggerated to make people more likely to be careful.  The
danger isn't a conventional exploit that would allow running of arbitrary
commands, as the fact that if the user can write to the _darcs/prefs
directory (which they shouldn't be able to, but I've never done an audit to
try to prevent) they can enable testing, which then allows them to run
whatever code they like.  Or, of course, if you have testing enabled they
don't even need to find a darcs bug, since you're intentionally running
whatever code they push.

Part of the reason I haven't worried too much about this issue is because
my feeling is that the best use of darcs *is* to run tests on a push
server.  It saves developers the trouble (and time) of testing each change
they make, since the test can be run by the server while they go on to do
other things.  Of course, it depends on the time the tests take, but the
longer they take, the more developer time is saved (up to the point where
the server can't keep up with all the patches being submitted).

That being said, it should be possible to lock down a push server--and not
all that hard.  Basically, you need to keep _darcs/prefs/defaults from
being modified.  Ideally darcs apply would never modify this file, but at
the moment darcs is trusting of patches, so a simple

hunk ./_darcs/prefs/defaults
+apply test

would enable testing.  The way to get around this is using user
permissions.  You need to make _darcs/prefs/defaults owned by someone other
than the user that does the patching.  Then to prevent deletion and
recreation of _darcs/prefs/defaults, you need to chown _darcs/prefs as
well.  Finally, to avoid a patch like (assuming you use procmail...)

hunk ./../.procmailrc
+bad stuff

you need to make sure that there are no other files or directories
writeable by your user that could lead to eventual execution.  This trick
also is something that really shouldn't be allowed, but is also something
that isn't very easy to prevent.  With all this complexity (and I'm far
from a security expert, so I'm sure there are issues I haven't thought of),
it seems easiest (and perhaps also best) to simply assume you are giving
execute access to any users you give write access.

On the other hand, it has just occurred to me that if I allow --no-test as
a flag to apply (with it overriding --test) then you wouldn't have to worry
about securing _darcs/prefs/defaults... I've just made this change, and
slightly updated the documentation to refer to it.  
-- 
David Roundy
http://www.abridgegame.org/darcs