Feature request: restricted keys (append only key, delete only key, etc)

[infokiller]

Have you checked borgbackup docs, FAQ, and open Github issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

This is a feature from Tarsnap that I'd like to have. See the short security overview for the basic description, but the idea is to be able to support multiple keys in a repository, where each key can be granted individual permissions. For example, this makes it possible to define two keys:

1. Append only key- can be used only for adding new archives to the repository
2. Delete only key- can be used only for deleting archives

This improves the security of the overall backup setup by implementing the principle of least principle.

[motwok]

The Crypto is used to protect the "privacy" of the backup data.

There is already a way to do a "append only" protection: borg serve --append-only works with ssh access (needs some configuration on the serverside)

Emmo

[infokiller]

@motwok thanks, append only protection is indeed close to what I'm proposing, but we can still benefit from more fine grained access control. For example, there could be a key that authorization for appending one backup a day, but that's it. The key can't be used to delete archives or even read them. Similarly, there could be a key just for restricted pruning (so that an attacker who gains access to the key won't be able to do aggressive pruning to delete data).

[ThomasWaldmann]

iirc we already have some issue about this on this issue tracker.

[motwok]

@infokiller I agree some kind of access control would be neat.

Besides of the effort needed to support session keys (some asymetric key crypto is needed) i can imagine a secure scenario for management (delete, prune, list), data access (decrypting content) and appending by using a separate key for access to metadata, contentdata and appending. (just a pre-alpha-thought[TM])

[ThomasWaldmann]

#8837 implemented BORG_REPO_PERMISSIONS=read-only env var - most of the repo will be r/o then, except the locks/ directory.

It also implements BORG_REPO_PERMISSIONS=no-delete - with that, destructive operations (like delete and overwrite) will be denied for the archives/ and data/ directories.

This is only implemented for the posixfs backend of borgstore (which is used by borg for file: and ssh: repos).

If one uses some other kind of repo (e.g. cloud), this needs to be implemented by cloud/server-side permissions configuration.

I will check if we can have a mode that only allows archives to get deleted/pruned. Considering that this is a very minimal operation in borg2 (it basically just kills a pointer from archives/, potentially orphaning the whole reference tree of the archive), it might be easy to implement.

[ThomasWaldmann]

Only allowing archives to get deleted (and NOT allowing archives to get listed or extracted) currently can't be done with BORG_REPO_PERMISSIONS, because all these chunks are stored together below data/:

• the main archive metadata chunk (archive name, timestamp, etc.)
• the items metadata stream chunks (names of files, file metadata, ...)
• the file content data chunks

[ThomasWaldmann]

That tarsnap approach with different cryptographic keys is quite different from the simple permissions check from my previous post - interesting!

[Jorge-Fabregas]

Hi @ThomasWaldmann,

Great to see this - it's encouraging to witness the beginning of a new "append-only" feature (or something heading in that direction). I'm really looking forward to it.

Just to clarify: this is for the scenario where you don't fully trust the client—e.g., where malware or an intruder could potentially wipe both your data and your backups. In that case, is the following the intended setup?

Once PermitUserEnvironment yes is set in sshd_config, the idea is to configure the authorized_keys for the borg user on the SSH server like so:

KEY1: For regular, unattended daily backups (append-only):

environment="BORG_REPO_PERMISSIONS=no-delete",command="borg serve --restrict-to-repository backup/main",restrict ssh-ed25519 my1stkey...

KEY2: For manual non-regular runs (for delete/prune/compact & the rest):

environment="BORG_REPO_PERMISSIONS=all",command="borg serve --restrict-to-repository backup/main",restrict ssh-ed25519 my2ndkey...

Is that the intended setup?

Also, will the no-delete environment option immediately block delete/prune commands? Or will it behave more like now where those commands proceed but no actual deletion happens until a compact is run (and that's where it will be blocked)?

Just guessing based on your post above, it sounds like delete requests will be blocked right off the bat (which I like). However, a compact operation - which works at a lower level with chunks - would still proceed and remove unreferenced chunks (i.e., data that was deleted earlier using a full-access key). Is that correct?

Thanks.

[ThomasWaldmann]

Yes, guess that is a setup that should work.

The permissions are enforced at the borgstore api level. If e.g. deleting an object is tried, but not allowed, it will raise a PermissionDenied exception. It won't be pretty.

Just keep in mind that it will only work for posixfs (file: and ssh: repos) and for production purposes it makes only sense for ssh: (as only there you have a separation between client and server, making it possible to enforce permissions on the server side, protecting against a malicious client).

Yes, if you run compact (with all permissions), it will do its job, which is removing all unreferenced/unused chunks. But if your daily backups run with no-delete and some other ops maybe even with read-only, it can't delete or prune archives or do any other stuff that would overwrite/delete/un-reference something.

[Jorge-Fabregas]

Thanks @ThomasWaldmann. This is looking perfect!