Roger Lucas wrote:

>Hi Andrew,
>
>Thanks for your reply.
>
>  
>
>>-----Original Message-----
>>From: Andrew Sullivan [mailto:ajs at crankycanuck.ca]
>>Sent: 23 January 2006 15:46
>>To: Roger Lucas
>>Cc: 'Andrew Sullivan'; slony1-general at gborg.postgresql.org
>>Subject: Re: [Slony1-general] Security with slony
>>
>>On Mon, Jan 23, 2006 at 12:30:53PM -0000, Roger Lucas wrote:
>>    
>>
>>>The network topology is very stable.  Once we have set up the node
>>>master-slave topologies we want to:
>>> - Absolutely lock this configuration in concrete
>>> - Absolutely ensure that slony can never write to the master "primary"
>>>namespace
>>>      
>>>
>>I think that requirement 2 is unreasonable.  That's like saying you
>>want to make sure that the VACUUM user can never write in the primary
>>namespace.
>>
>>If I were designing such a system, I'd do it with two steps: node A
>>replicates to node B, and node B chains down to everything else.
>>There should be no listen paths from A to {C. . . Z}.
>>
>>But it sounds like what you need is a functional host-based ACL
>>system grafted on top.  That is, events of type T can come only from
>>nodes {some set of nodes}, and other events of type T' can come from,
>>&c.
>>
>>    
>>
>
>That would be ideal... but I cannot find it in existance already.
>
>  
>
>>>Looking at the slony documentation, it suggests that slonik would not be
>>>      
>>>
>>run
>>    
>>
>>>very often in the above scenario, so we could use ssltunnels to link the
>>>sites for the configuration commands and then remove these tunnels to
>>>prevent the node configuration from changing.  Firewalling of all
>>>      
>>>
>>incoming
>>
>>No, you seem to misunderstand.  Slonik injects events, just like any
>>other kinds of event, into the replica stream.
>>    
>>
>
>That confuses me, as I had read the information below to imply that the
>network configuration commands (i.e. control messages from the
>"administrative workstation" that set up the topology of the replication
>network) were sent "out of band" using different links which could then be
>shut down when not required.
>
>http://linuxfinances.info/info/plainpaths.html
>("ADMIN CONNINFO" section at the top)
>  
>
The *requests* are set out in a potentially "out of band" fashion, using
slonik.

But some of the processing takes place using the slon process (e.g. -
the event processor). 

For instance, when a node is set up as a subscriber to a set, you'd use
slonik to submit the "subscribe set" request.

That turns into a "SUBSCRIBE_SET" event, which slon passes along.  And
it's slon, doing event processing, which has to alter the tables in that
replication set, hiding any existing triggers, and adding in the ones
that Slony-I wants.

As a result, the component that needs to be trusted-as-superuser is the
slon event processor.

>I don't want to generate too much noise on this mailing list as it is
>relatively low volume, however, so I'll dig through the code to try to
>understand its workings in more detail rather than ask more questions.
>  
>
I suppose this is displays that the splitting of work across slon/slonik
hasn't been done with a view to trying to get as many bits as possible
to be achievable with consciously minimized access privileges.  The
assumption was always that slon/slonik would need to operate as a
superuser because some parts require that.

It would be an interesting analysis to determine which parts of that
truly need superuser access and which don't, with a view to minimizing
access privileges.  That would lead to some fairly significant changes,
I'm sure.  I imagine be necessary to shift certain changes over to be
done by Slonik, or for there to be some sort of "superuser event queue"
that would block "normal events" until someone logged on as a superuser
to process the "super events."

An open question is whether the effort would actually help.  I'm more
than a little skeptical of that.  But given a Schneier style "Attack
Tree" <http://www.schneier.com/paper-attacktrees-ddj-ft.html> or other
decision tree that maps this against a model of someone's security
requirements, I'll bet interesting things could fall out.