syncoid: paranoid permissions

[lachesis]

In this era of ransomware and APTs, we would like to ensure that even if our application servers are fully compromised, the attacker will not be able to delete the backups. Furthermore, we potentially intend to back up several mutually untrusting hosts (think customer-controlled VMs) with syncoid to a single trusted backup server. I've see the --no-privilege-elevation flag. However, I see in #660 that zfs destroy is a required remote permission. If we were to give the syncoid user that permission, then an attacker would be able to destroy all datasets on the remote backup machine. In my mind, it would be ideal if syncoid could operate with nothing more than the ability to execute zfs receive and zfs list. We can do snapshot pruning directly on the backup server, ideally with a sanoid configuration. So... is there any way to configure syncoid as I want?

[redmop]

Doing pull backups goes a long way to help with that.

[secabeen]

Pull backups is the right solution, where the backup server logs into the production box and sends the commands needed. That said, there was a previous issue describing how a malicious production server could fabricate a replication stream that contained delete actions enough to damage data on the backup server. It would require a pretty skilled attacker to leverage that. For me, pull backups are enough.

[xpufx]

In my testing with PULL backups, hold,send,snapshot on the dataset being backed up is enough if you specify '--no-sync-snap'. Destroy is required for deleting the interim snapshots syncoid creates of the data. I didn't want to give this permission so I am using it this way. I can probably remove the snapshot permission too.

Is there a big potential problem with '--no-sync-snap' ?

[putnam]

An interesting note about using pull backups:

If you want a trustless offsite with raw encrypted backups, the last thing you want is for that server to be able to do arbitrary zfs sends from your (presumably mounted, keys-in-RAM) dataset. So far I have not found a way to resolve this besides using raw push backups only.

[jsddsfoh]

i use sudo on my offsite with push backups. visudo offsite:

# Syncoid commands backupuser ALL=NOPASSWD: /usr/sbin/zfs get * backupuser ALL=NOPASSWD: /usr/sbin/zpool get * backupuser ALL=NOPASSWD: /usr/sbin/zpool list backupuser ALL=NOPASSWD: /usr/sbin/zfs receive * backupuser ALL=NOPASSWD: /usr/sbin/zfs list* backupuser ALL=NOPASSWD: /usr/sbin/zfs rollback -R remotepoolname* backupuser ALL=NOPASSWD: /usr/sbin/zfs send -w -L -e -c -p remotepoolname/datasettosendback* backupuser ALL=NOPASSWD: /usr/sbin/zfs send -w -L -e -c -p -I remotepoolname/datasettosendback* backupuser ALL=NOPASSWD: /usr/sbin/zfs send -w -L -e -c -p -nP -I remotepoolname/datasettosendback*

I hope it's as secure as I think :D The send lines are for backup a dataset from offsite, it's a backup of the offsite machine.

Delete old snapshots is done by sanoid offsite, with just autoprune and no autosnap.

[phreaker0]

@lachesis destroy should only be needed if you want your source to destroy snapshots on the target (sync snaps) with the option --no-sync-snap it shouldn't be needed. @jsddsfoh rollback is pretty dangerous for this use case as it will destroy snapshots

[jsddsfoh]

@lachesis destroy should only be needed if you want your source to destroy snapshots on the target (sync snaps) with the option --no-sync-snap it shouldn't be needed. @jsddsfoh rollback is pretty dangerous for this use case as it will destroy snapshots

https://openzfs.github.io/openzfs-docs/man/master/8/zfs-rollback.8.html It can indeed destroy snapshots, thanks for the heads up! So I need to use syncoid with --no-rollback.