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 db.mtn". 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 db.mtn 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 - http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf) > 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. -Jack _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
