[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] db kill_rev_locally

From: Daniel Carrera
Subject: Re: [Monotone-devel] db kill_rev_locally
Date: Sun, 12 Oct 2008 00:57:52 +0200
User-agent: Thunderbird (Macintosh/20080914)

Jack Lloyd wrote:
I would not recommend running Monotone setuid root!

For one thing, it is not required. Monotone runs fine as a regular
user. You would be far safer running Monotone setuid as some
non-privledged user. (In which case what you suggest is a good idea
for mediating access through the mtn binary)

You are right. Your idea is much better.

I am the author of Botan, which is a library used in Monotone. I could
not even be sure that Botan is safe to use in a setuid program.

It's wise to not run setUID root if you don't have to. And you've shown that Monotone doesn't have to. A secure server would make a custom user just for Monotone, similar to how Apache runs as its own user. That would be a great way to restrict access to the database and ~/.monotone.

The problem of malicious insiders is well established and there are a
number of known solutions to mitigate the risk. But these solutions fall
apart if a program that insiders are supposed to run is insecure.

I do think that Monotone's current authorization control system is far
too simplistic.

Perhaps. But I wanted to suggest only a small easy change in the hopes that it would be more acceptable to developers.

I am writing a paper on the security of Monotone. I'm following David A. Wheeler's paper on SCM security:

You may be interested to know that Monotone seems to do very well against David's criteria except for the concern over malicious developers or attackers with stolen credentials. If Monotone had a config file where you could disallow certain commands, that would be enough to make it do impressively well against David's criteria. The only feature missing would be support for encrypted branches.

But as of today, the presence of "db execute" is a major security gap. Especially because the only way to fix it (deny SSH access) opens a different security gap (trusted paths).

If you are interested, I'd be happy to show you the paper when it's one. I expect to finish tomorrow.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]