For example, if the forget policy is to keep three weekly snapshots, and the attacker adds an empty snapshot for each of the last three weeks, all with a timestamp (see the backup command’s --time option) slightly more recent than the existing snapshots (but still within the target week), then the next time the repository administrator (or a scheduled job) runs the forget command with this policy, the legitimate snapshots will be removed (since the policy will keep only the most recent snapshot within each week).
forget --keep-within already solves the problem, but it would be nice to be able to also use the other forget options.
Would it be useful to add a setting to:
reject snapshots with a date (significantly) differing from the current date
or a setting to make the rest server always set the snapshot date to the date, which was current at the time of receiving the snapshot (no idea whether the server is able to modify the snapshot’s date without violating the snapshot’s integrity)
Can you give a more concrete example of problematic snapshots and how your suggestion would solve the problem? I’m not sure I understand why you think there’s a need for a different solution.
Regarding REST-server, it’s not really something that deals with the contents of the repository, it basically just shuffles data to and from files as per what restic asks it to do.
Need for a different solution:
With forget --keep-within you have to keep all snapshots within the specified time span. It is, e.g., not possible to only keep a single snapshot for each of the last three weeks as described in the quote.
I hope that with my suggestion a malicious client can not create a snapshot in each of the past three weeks, so that it would be safe to keep a single snapshot for each of the last three weeks.
Step A
Original snapshots:
Week 1: S1 (from Friday)
Week 2: S2 (from Friday)
Week 3: S3 (from Friday)
Step B
In week 4 the malicious client creates 3 snapshots with past dates:
S1* (dated at Saturday in week 1)
S2* (dated at Saturday in week 2)
S3* (dated at Saturday in week 3)
Step C
Then the admin runs forget with the option to keep a single snapshot for each of the last three weeks. As a result, S1*, S2* and S3* will be kept, but not S1, S2 and S3.
With my suggestion the malicious client would get an error in Step B and in Step C S1, S2 and S3 would be kept.
The rest-server is unable to read the snapshots due to encryption, which makes it impossible to prevent clients from adding manipulated information there.
It might be possible to expose the file modification timestamp from the server and use that for some kind of sanity check. However, that will requires quite a few changes in restic, rest-server and maybe even the protocol between both. Thus, I have no idea when we might be able to get around to implement that idea.
Something like a repo plausibility checker would be good for this extra security. It could run run locally on the backup server by a cronjob before restic forget. It could check if timestamps of certain files matches the snapshot timestamps and also check the snapshot size (e.g. must be greater or equal than last snapshot).
Each of these checks only makes sense in certain environments. I’m not sure whether it would be possible to implement something universally useful. Most likely, some environment specific checks based on the output of some restic commands would be more effective.