[Top][All Lists]

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

Re: [Monotone-devel] db kill_rev_locally

From: Daniel Carosone
Subject: Re: [Monotone-devel] db kill_rev_locally
Date: Sun, 12 Oct 2008 08:30:33 +1100
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Oct 11, 2008 at 11:20:50PM +0200, Daniel Carrera wrote:
> Nathaniel Smith wrote:
>> No, it simply wipes out the revision and its certs, as if they never
>> existed.  (Except that as you note, it does leave some of the
>> associated data behind in the database, but there's no way to get at
>> this data except by poking around in the db by hand.)
>> This isn't really a security issue, though, because it only affects
>> the database that it's run on.
> Yes it is, because it easily allows a DOS attack from a malicious  
> developer or someone with a developer's credentials and there is no way  
> to identify the attacker. 

No. It doesn't require (monotone) credentials (ie, key).  It is
applicable only to those who have write access (at the OS level) to
the developer's database. 

A malicious developer can only hurt himself, he can't publish
something with his key that will kill revs from other users'
databases.  An attacker with write access to the developer's local db
storage can do whatever he likes to that storage, regardless of code
we might write in a mtn executable.  The attacker can use sqlite
directly to manipulate the database, or raw byte manipulation if he

> Against this particular attack, Monotone only has recovery. Monotone has  
> a great recovery system, but something in the way of prevention or  
> detection would be a worthy improvement. For example:
> 1) Prevention: Remove or somehow restrict the "db kill_rev_locally"  
> command and the "db execute" command.

See above, the attack is outside the scope of this command to prevent.

> 2) Detection: Record who runs "db kill_rev_locally" (recording "db  
> execute" is kind of pointless).

And this record could also be removed when manipulating the database

The point about recovery is good, though - many other kinds of raw
manipulation of the database will be detected as corruption, and not
trusted without valid signatures.  Destruction of information can only
be addressed by replication.


Attachment: pgpaXg7cT12Xy.pgp
Description: PGP signature

reply via email to

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