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