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?


Jan

On 2/3/2006 7:12 AM, Roger Lucas wrote:
> Hi Andrew and all,
> 
> Sorry for the delay in my reply, but things have been a little busy here
> recently....
> 
> Here is my summary in for the security problem that I am trying to solve.
> An outline proposal for a method to resolve it follows.  I apologise in
> advance for the recap of information from older mails, but hopefully this
> mail can be used as a single point of reference going forward.
> 
> Security Problem
> ----------------
> 
> At present, all Slony daemons run with postgres SuperUser privileges on
> their connection to their local node.  In addition, the daemons include
> login information in plain text for postgres accounts with SuperUser
> privileges on all other nodes that the daemons must communicate between.
> This allows them to reconfigure the other nodes automatically then the
> replication hierarchy changes.
> 
> Unfortunately, these privileges are preserved during normal operation, which
> has no requirements for such high privileges (just write permissions on some
> tables and read permissions on some others).  
> 
> This means that if the security of any Slony node is compromised at any
> time, then the attacker not only has access to the local SuperUser password
> (which they may be able to get in many ways having compromised the machine),
> but they have been given all the SuperUser passwords to other machines in
> the Slony replication system.  They can then open connections to other
> databases in the system using these SuperUser logins and then recover data
> from from, change the data or even delete the data completely.
> 
> There is even the risk that once an attacker has gained access to a Postgres
> database with SuperUser privileges, they could leverage these privileges to
> access other files on the system allowing the security breach to be
> worsened.  Hence, compromising one machine with Slony running may allow the
> attacker to quickly compromise every machine on the network which has Slony
> running.
> 
> To me, this represents an unacceptable security risk.
> 
> I accept that the Slony daemon may require SuperUser (or more precisely, a
> significant set of privileges) occasionally, but I cannot see strong
> justification for leaving these privileges permanently granted when they are
> not required.  This goes against all recommendations I have ever seen on how
> to develop and maintain secure systems.  
> 
> I feel that there must be a way to reduce the privileges of a Slony daemon
> while it is running "normally" and not in the process of reconfiguring the
> replication hierarchy.  Then, even if a machine has been compromised, its
> ability to wreak havoc through the rest of the system is dramatically
> reduced.
> 
> 
> Outline of recommendation
> -------------------------
> 
> I suggest that a set of "reconfiguration" and "operation" privileges are
> determined.  A specific slony-daemon account would then be created which the
> slony daemons use when logging in to other nodes.  Under normal operation
> this account is only given the "operation" privileges.  These lock the
> daemon down to only being able to read tables that need replication or are
> used to manage the replication and only being able to write to tables that
> are targets of replication data or are used to maintain the replication
> state.
> 
> When an administrator wishes to reconfigure the replication hierarchy, which
> would be a relatively rare event, then they can explictly log in to
> appropriate Postgres databases and temporarily grant the slony-daemon user
> the "reconfiguration" privileges before starting the reconfiguration of the
> replication hierarchy.
> 
> Once the replication has been reconfigured, a "release privileges" action
> could be performed to drop the Slony postgres users back to an appropriate
> privilege level for the new network.  If possible, the Slony daemon would
> automatically determine what their minimal privilege requirements from
> studying its replication needs and can then release all but these
> privileges.  This would then then it to work normally during replication.
> 
> There is still a security risk when the replication hierarchy is
> reconfigured, but since these events are rare, and the administrator may
> perform additional security checks before performing the replication
> hierarchy changes, this would give a dramatic reduction to the security
> risks present in the system.
> 
> I would welcome comments and suggestions on this proposal.
> 
> Best regards,
> 
> 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 #