In the scenario where a client computer with access to files via a network share becomes infected and encrypts files, but the server is snapshotting the file system that those files are stored on.
Also, OpenZFS can export ZVOLs over iSCSI so you can have formatted block storage for other devices that can be rolled back by snapshot on the OpenZFS.
In a virtualized environment all of the VMs' storage could be protected with snapshots.
There's a number of reasons I feel this assumption is valid in most cases:
1) Unless it's a targeted attack it's highly unlikely that a ransomware strain will be designed to target a specific filesystem. Snapshot deletion requires filesystem specific APIs, whereas reading/writing files is just standard libc fare. You would need to maintain different strains of a virus to target an organization running Btrfs vs ZFS vs ReFS, for example. - If the attacker has deep knowledge of your storage stack, and has gained privileged access to it, you've already lost: go to step 4.
2) Separation of privileges. Deleting a snapshot is a privileged command. A ransomware infection that doesn't successfully elevate privileges might be able to encrypt my home directory, which would suck, but it wouldn't have permissions to delete snapshots of my home directory.
3) Virtualization / network storage: snapshots are transparent to virtual guests, a virus inside a guest can't delete snapshots if it's not aware they exist. With network shares and ZFS: you can choose whether or not you want to expose snapshots. If you do expose them: don't grant network clients privileges to delete them.
4) Replication: with any ransomware infection the only real defense is off-site backups. Snapshots makes backups trivial. You can incrementally replicate and restore from them easily (e.g: zfs send/recv.) This alone makes using a CoW filesystem worthwhile in the defense against ransomware. Ransomware will have a hard time deleting snapshots on an air-gapped disk.
"Why would ransomware that can encrypt all your files not be able to delete your snapshots?"
If you keep your backups on a third party cloud storage provider that runs on ZFS then those snapshots are taken by their root, not yours.
You send your backups to this cloud storage provider and they take the snapshots on your behalf.
You have an unprivileged login and have the ability to read the snapshots, but not destroy them.
In this scenario, Mallory can destroy your data and gain access to all of your cloud credentials and destroy the primary dataset ... but cannot destroy the snapshots.
I'm sure there must be some cloud provider, somewhere that offers this ... right ?
Your service does so and does so well but I would go further and say that any service that does not is not suitable as a backup solution. No matter if the service runs tapes the customer can't decide to overwrite, snapshots they can’t remove or whatever solution they use, the customer should not be able to delete old versions prematurely.
If there was ever a use case for certain operations to require a privilege level higher than or separate from root, snapshot deletion is it. I’m generally a bit skeptical of such measures, but the purpose here is obvious.
I don't see how that is anything more than adding an additional hurdle that the attackers would overcome. If they can already jump through the hoops to get root access then what's to stop them from doing the same for this other theoretical access level?
The user may have granted root access to do something relatively normal and unrelated to ZFS. You probably only want one or two programs to ever be able to delete snapshots.
This is a permission which can be delegated to users on a per-dataset basis. See "zfs allow". It didn't used to work on Linux, but has been possible since Ubuntu 20.04.
Often ransomware runs with user or local admin access since all they want to do is encrypt your work files. Hopefully deleting snapshots would requite a different level of access.
