More borg serve restrictions for key control

[verygreen]

There's already borg serve path restriction.
There's some value in adding more:
--append-only (currently only option in manifest)
--write-only / --restore-only - there are some limitation about this now, but still should be possible to do something here I think.

The idea is to use ssh force-command with borg serve.
So I have a trusted key that can do everything and a key that's for regular backups - no ability (or very limited) to read stuff, no ability to delete (--write-only is not only about not reading, but delete prevention, like prune and stuff).
And possibly yet another key just for restores that cannot modify anything at all.

[enkore]

--append-only (currently only option in manifest)

Makes sense

--write-only

A bit hacky - only allow to read 00000000..00 (manifest)? (uh, no, chunk cache sync!)

--restore-only

(--read-only): simple, allow no commits (or just fail on PUT/DELETE etc.)

[verygreen]

A question about chunk refcounting - is that managed by the server (hopefully)? Or at the very least, the writes can only make the count go up, not down, right (so disallowing prunes/deletes with --write-only is fine).
Oh! I guess the other glaring hole is they can always write an empty manifest if they are dedicated (or delete already does it for tehem clientside anyway), so likely right now --write-only would imply --append-only?

[enkore]

A question about chunk refcounting - is that managed by the server (hopefully)?

No, that's not in the repository, but in the local cache of each client.

so likely right now --write-only would imply --append-only?

edited my comment above, the chunk cache sync needs data access (at least the metadata chunks, but the server can't technically tell these apart). So --wo wouldn't really work out

[verygreen]

I think chunk cache sync is ok? It does not rellly transfer entire chunk content to the client, just some hash (and a refcount?) - so that does not give the attacker much.
If we restrict the chunk contents from being transferred (except the manifest), that should be ok, no?

[verygreen]

Also if metadata chunks cannot be really told apart - cannot we force operation with no cache? After all we believe local client already has cache and does not need rebuild - this might be an ok design constraint for the usecase?

[enkore]

Also if metadata chunks cannot be really told apart - cannot we force operation with no cache?

Yes, but that's just the file metadata cache, not the refcount cache. borg-create can't work without a cache, although it could be made to cope, which would solve that part of the issue. This may actually be desirable performance-wise in a typical multi-client workload (many creates, few restores).

[verygreen]

I think small steps is the way?

step 1: Require client to already have the chunk cache (meaning 1:1 mapping of client to repo) - for such write only mode clients only! Security requires sacrifices after all ;)
step 2: Make clients cope if they have no cache whatsoever (could be a protocol change like "I have hash X, do you need it?" or other mechanisms including just sending it anyway and server dropping it on the floor as one of the least desirable options. Also partial caches for multi-client workloads, where server would also tell a client something like "hey, thanks for the chunk, but I already had it anyway", hich might not even be necessary since why would the client care.

[ThomasWaldmann]

Moved the easy part to #1168 (following the rule to not mix different stuff into 1 ticket).

[textshell]

The design of borg is done around a rather simple server that doesn’t know anything about the internal structure, in encrypted mode it can’t even see any of that structure. So i think a more natural approch would be to go via encryption to keep clients from reading the data. I think the information needed for deduplication (if enabled) and the metadata needs to be readable by a client doing a backup. But if the client could store the non metadata with a session key that is asymmetrically encrypted and it does not have the key to later decrypt it, than the server can concentrate on blocking deletes and doesn’t need to care about reads.
Backup only keys would only contain the metadata key (likely symmetric like the current setup) and the metadata only contains the public part of the non-metadata key. Full keys would contain the metadata key and the private part of the non-metadata key.

I’m not sure if the directory structure of a backup still needs to be counted as metadata here or can be seen as non-metadata. I think realistically the backup only key would still be able to get the HMAC of all chunks stored in the backup so it could still do finger printing of backuped data.

[PlasmaPower]

--append-only will be added to 1.0-maint with #1229 (fixing #1168) which will be merged soon.

Edit: it's been merged.

[ThomasWaldmann]

Another relatively easy mode might be the "no-delete mode" in #1772.