Even if this discussion is quite old and almost everything has already been said, I think the env variable RESTIC_PASSWORD_COMMAND can be used to prevent modifying or deleting backups as well. In combination with pass (the standard unix password manager) and a pgp key which is stored on a security key, your backups will be protected against malware, ransomware and hacked web servers as well. But of course as @rawtaz @nicnab and others already mentioned, this won’t help you anything if your sys-admin or root can already read all your plain-text stored files.
1 Like
Unfortunately not. The RESTIC_PASSWORD is only necessary to decrypt data stored in the repository. But for a ransomware attack it’s enough for an attacker to just wipe all files in a backup. The access controls in that regard must be implemented at the storage side (see append-only backups with rest-server).
2 Likes
I had the similar task half a year ago: how to keep storing restic repository password encrypted (in 1Password in my case) and avoid using plaintext files with them.
So I developed some kind of scheduler and password manager in one:
- I runs restic (or any other command actually) when it’s needed
- Controls parallel runs
- Uses in-memory storage for password read from 1Password and provides them with one-time token to restic via RESTIC_PASSWORD_COMMAND
As a result there are two attack vectors for that setup:
- Fit into time window between one-time token is generated and passed to restic and restic redeems it which is less than 50ms and requires sufficient privileges and skills on Unix systems
- Cold boot attack which is really difficult
And as opposite: no chance to expose the password via environment no matter what privileges the attacker have (root user can read environment of any process in Linux and macOS) and no need to store anything unencrypted in the filesystem.
In addition I use S3 policies to cover some risky places to disallow the user which is used to store backups to delete anything.
I will probably open it one day on GitHub but now it’s kinda rough for that and I actually really wait for Go API to use restic as a just dependency but binary - this will ease many things and will allow to increase security.
1 Like
If an attacker has root privileges then its pretty trivial to capture the password. But in that case you’ve already lost anyways.
All it takes is a small bash script that wraps the restic binary and that just hijacks the RESTIC_PASSWORD_COMMAND to also store a copy. I’d say its less than 10 lines of code without any timing issues.
1 Like
That’s possible to get the password faster than restic - that’s what I said, it’s not an ultimate solution and that’s why I waiting for Go API.
But In your case if you just copy RESTIC_PASSWORD_COMMAND you also need to run it before restic to grab the password and restic backup will fail in that case since it will fail to retrieve the password, so monitoring of backups is a part of it.
However comparing to the password stored in plaintext it dramatically reduces the risk of repository password exposure and that’s why I’m using that approach 
1 Like
Sure, it’s an improvement to storing the password in plaintext.
What I had in mind is to hijack RESTIC_PASSWORD_COMMAND as follows, which is trivial to do for a restic-wrapper script: RESTIC_PASSWORD_COMMAND=/bin/bash -c "$RESTIC_PASSWORD_COMMAND | tee /key-leak" (I’m pretty sure that syntax is subtly broken somewhere)
1 Like
That’s the case I also tried to solve btw, but there’s no reliable way to verify (sha256) and exec the binary or load Go plugin atomically, unfortunately
1 Like
You can use githooks dialog tool (which is bomb proof) and platform independent (needs zenity though on linux).
~/.githooks/bin/dialog entry --title "Restic Backup" --text "Enter the password:" --hide-entry
use with RESTIC_PASSWORD_COMMAND by putting it into a script, make it executable and assign this to the variable.
1 Like