[Top][All Lists]

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

Re: [Monotone-devel] db kill_rev_locally

From: Jack Lloyd
Subject: Re: [Monotone-devel] db kill_rev_locally
Date: Sat, 11 Oct 2008 18:37:55 -0400
User-agent: Mutt/1.5.16 (2007-06-09)

On Sun, Oct 12, 2008 at 12:01:16AM +0200, Daniel Carrera wrote:

> I understand where you are coming from. An attacker with arbitrary shell
> access could just run "rm". But there are ways to mitigate that
> risk. You could give them a custom shell that only allows running one
> command: mtn. You can also make and ~/.monotonerc belong to root an
> run mtn with the set-UID bit like the mount command.

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)

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. And of
course Monotone is much larger than just one library, and interacts
with both the filesystem and the network. In general running a program
setuid root that is not explicitly written to be setuid is very
dangerous - there are a lot of ways to mess up, even if you are being
careful (if you haven't seen it, "Setuid Demystified" explains some of
the common failures -

> 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. I liked the authentication system Shapiro designed for
OpenCM. It was simple, could be very fine grained if required, and was
easy to manage project access controls. A design change the Monotone
designers call policy branches may or may not fix a lot of the
perceived shortcomings of the current model. I know there was an
implementation of policy branches going, but I don't know if it was
completed. It certainly is not included in normal releases.


reply via email to

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