SECURITY: Privilege separation for archive_command & other Barman functions

[japsu]

Consider a common setup where user postgres on pg runs a PostgreSQL server and barman on backup runs Barman, and postgres@pg has passwordless SSH pubkey access to barman@backup to perform the recommended

archive_command = 'rsync -a %p barman@backup:/var/lib/barman/pg/incoming/%f'

Now consider a situation where the postgres@pg user is compromised and an attacker gains shell access on that user. They can now ssh barman@backup and silently corrupt the backup.

To prevent this, we need privilege separation between archive_command and other functions of Barman.

We might be able to solve this without changes to Barman, for example by leveraging forced commands in authorized_keys, or by using another user to perform the archive_command and UNIX privileges to separate it from the rest of Barman, or some combination thereof.

A heads-up in the documentation and an example configuration mitigating this would be appreciated.

[japsu]

An obvious way to mitigate this is to opt out of using WAL shipping (archive_command) and only use WAL streaming. But the documentation explicitly recommends using both.

[gclough]

Also consider what happens when you have several servers being backed up to the same barman server:

pg01 --+--> barman01
pg02 --+
...    +
pg99 --+

You can ssh from postgres@pgXX -> barman@barman01, and then any compromise of ALL backups for ALL of them.

ALSO, if you're doing remote recovery ("definitely the most common way") then you need ssh from barman@barman01 --> postgres@pgXX, then any compromise of ANY of the postgres servers can be relayed via the barman server to access ALL of the postgres servers:

postgres@pg01 --+--> barman@barman01 --+--> postgres@pg01
postgres@pg02 --+                      +--> postgres@pg02
...             +                      +
postgres@pg99 --+                      +--> postgres@pg99

That sounds a little worrying... but I'm new to Barman, so am I getting that right?

http://docs.pgbarman.org/release/2.4/#one-barman-many-postgresql-servers

One Barman, many PostgreSQL servers
Another relevant feature that was first introduced by Barman is support for multiple servers. Barman can store backup data coming from multiple PostgreSQL instances, even with different versions, in a centralised way.

http://docs.pgbarman.org/release/2.4/#preliminary-steps

From PostgreSQL to Barman
The SSH connection from the PostgreSQL server to the backup server is needed to correctly archive WAL files using the archive_command setting.

To successfully connect from the PostgreSQL server to the backup server, the PostgreSQL public key has to be configured into the authorized keys of the backup server for the barman user.

The public key to be authorized is stored inside the postgres user home directory in a file named .ssh/id_rsa.pub, and its content should be included in a file named .ssh/authorized_keys inside the home directory of the barman user in the backup server. If the authorized_keys file doesn’t exist, create it using 600 as permissions.

The following command should succeed without any output if the SSH key pair exchange has been completed successfully:

postgres@pg$ ssh barman@backup -C true
The value of the archive_command configuration parameter will be discussed in the “WAL archiving via archive_command section”.

From Barman to PostgreSQL
The SSH connection between the backup server and the PostgreSQL server is used for the traditional backup over rsync. Just as with the connection from the PostgreSQL server to the backup server, we should authorize the public key of the backup server in the PostgreSQL server for the postgres user.

The content of the file .ssh/id_rsa.pub in the barman server should be put in the file named .ssh/authorized_keys in the PostgreSQL server. The permissions of that file should be 600.

The following command should succeed without any output if the key pair exchange has been completed successfully.

barman@backup$ ssh postgres@pg -C true