On 2/3/2006 12:34 PM, Roger Lucas wrote:

>> -----Original Message-----
>> From: Jan Wieck [mailto:JanWieck at Yahoo.com]
>> Sent: 03 February 2006 15:58
>> To: Roger Lucas
>> Cc: 'Andrew Sullivan'; slony1-general at gborg.postgresql.org
>> Subject: Re: [Slony1-general] Security with slony
>> 
>> In the end, an attacker can fake events on the compromised node that
>> will be executed by the slon deamons against their local databases with
>> all the rights that are required. Therefore the outline below is just a
>> complification of an already very complex system. Unless you want to
>> introduce a fine grained node-event-permission system you don't gain
>> anything. And I don't see an easy way to tell if such event really
>> originated on that permitted node in a cascaded environment. Which means
>> you probably want to have every event digitally signed?
>> 
> 
> I must be missing something.
> 
> As I understand it, all slon daemons log into the appropriate Postgres
> databases using the login and password that is indicated in the STORE_PATH()
> line in the slonik script.  If the username given does not have superuser
> access then the slon daemon will not get superuser access, slon just gets
> the rights for that username.

No slon process ever updates any of the remote databases at all. They 
only ever insert, update and delete against the nodes local database. If 
it makes you feel better, you can put another user into the path info 
and set that user up for read only access of the slony schema. It should 
still work.

But keep in mind that all slon daemons simply do whatever they are told 
in the events they receive. So even without remote superuser access, an 
attacker can do almost all the damage he wants by simply injecting 
events into the compromised database. The events will be read by the 
slon daemons of the other nodes and they then do the damage on behalf of 
the attacker.


Jan

> 
> If that is true, then I should be able to reduce the rights on the slon user
> so that it only has (for example) write access to the tables that it is
> replicating to, read access for the tables that it is replicating from,
> read/write access to the slony configuration tables, and no access to
> anything else.  Hence, if an attacker gains access to a node, even if they
> can reconfigure the replication hierarchy, the other machines in the Slony
> network still have the appropriate user restrictions in the Postgres
> databases to stop the attacker from doing too much damage.  For example, if
> the slon user did not have write permissions on a master table that should
> only be replicated from (and should never be replicated to), then that table
> could never be corrupted by slon, even if the attacker tried to get slon to
> write to it in some way.
> 
> Is the above correct?
> 
> Thanks, 
> Roger.
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #