How do you create a cron job without exposing your restic password in plain text?
FAQ — restic 0.16.3 documentation says:
When you run
restic backup, you need to enter the passphrase on the console. This is not very convenient for automated backups, so you can also provide the password through the--password-fileoption, or one of the environment variablesRESTIC_PASSWORDorRESTIC_PASSWORD_FILE. A discussion is in progress over implementing unattended backups happens in #533.
1 Like
With the RESTIC_PASSWORD_FILE method you can secure the password file by restricting its access to minimise which user accounts can read it.
1 Like
So it means to store the password as plain text just next to the backup folder. I don’t call this “secure”
So it’s only a filesystem permission security. if someone dual boot or is root I can’t hide my password?
If your system is physically in the hands of an adversary you should consider it compromised, as they can read the system’s memory or tamper with it in other ways. The closes to “secure” you can get when an adversary has the system in their hands is if the system was shut down well in time before they got their hands on it and you use full disk encryption or similar.
If an adversary is root on your system, you should consider it compromised, as they have complete control over what runs on the system.
So in this context, storing your password in a file with proper permissions on it is not something that can prevent you from an adversary that already owns the system, naturally.
4 Likes
I think what the real question might be is this: will someone who manages to compromise my system also be able to compromise the backup location?
There are multiple ways to prevent that from happening. In my opinion the easiest way is to (a) have the backup server ssh into the system and execute the backup passing the backup password as a variable during the backup process. In addition you could (b) use rest-server on the backup server and only allow adding data so that even if keys were compromized the adversary would need root access to the backup server to affect existing backups up until that point in time.
1 Like
Maybe I should rephrase the question.
How to have an automated backup (with cron for example) without exposing my password to my colleagues and my boss (root) on a shared system?
I would like to not have a specific password for restic and if they can’t see and access what is inside the backup it’s even better.
I expect my colleague to do a “sudo cat mypasswordfile.txt” and not do advance hacking stuff.
Protection against curious colleagues: Put the password in a file and do “chmod 600” on it.
Protection against curious root: Not possible.
EDIT: If the colleagues can su/sudo and do stuff as root, then there is no protection against them either.
2 Likes
Simple: don’t safe the password. Enter it manually or by copy/paste every time you execute a backup. If you don’t provide it, restic will ask for it.
2 Likes
If you want it to be fully automatic then without a trusted root it’s not possible. For a manual operation you could store the key material on a hardware token but this would require activation for each backup run. If you want to secure the repository password from root on the system you’ll have to copy the data from a system you do trust.
1 Like
Exactly. You can, however, as stated above, use rest-server on the backup server and set it to --append-only. This way anyone who compromizes your password file is able to add files to your backup but never access or delete anything backed up earlier. This is also a good insurance against malware, ransomware and hacked web servers.
2 Likes
Thanks for your answer, I wish they were a way to give a secret to cron without an easy way to access it.
I guess I have to call the file tmp.log and hash my regular password to have something witch looks random as a password and is still convenient to use. But it will be quite obvious if they look at the cron config file.
I’m not sure what the X in XY is here in the first place. What relevant problem are you actually trying to protect against?
My point is that if your system has other users on it that are root or similar, you have to assume that they already have complete insight and access to all your data on this system, so that can’t be what you’re concerned about. It simply doesn’t matter that when they have this complete access, they can also access another copy of your data.
The thing left is protecting against them deleting or modifying your data somehow. As others have pointed out, the way to protect against that is to make sure that you have copies of the data that these adversaries cannot delete or modify.
One way to do that is to use restic to back up the data to a repository that they cannot delete or modify, e.g. using rest-server with --append-only. Another is to use restic or whatever other tool to back up or sync your data, and on the storage side use some kind of snapshots that not even restic or your sync software can affect, e.g. ZFS snapshots or whatever other storage you use. A third option is to pull the data to somewhere instead of pushing it somewhere.
So, it seems to me that you are concerned about something that isn’t very relevant, considering that your data is already completely in the hands of your fellow root/sudoers anyway.
What would be the point? They already have all your data, so what does it matter if they also have your backup password? If you want to protect against deleting or modification, you’d do your backups in another way in the first place.
What does it matter if they can see what’s in the backup, when they have already seen everything that went into that backup? You gain nothing.
So let them. They already have your data.
That is “security by obscurity” and never a good idea, like hiding your key under your door mat. As @rawtaz has pointed out, there is no such thing as a free lunch here. Just use rest-server --append-only and you’ll be fine.
1 Like
One thing came to my mind while reading this:
When a friend of mine discovered restic, he became very enthusiastic and would implement it very quickly on all of his webservers with one S3 bucket for each webserver. When he showed me his work I noticed that he would use the same access key on every server, which had permissions for every bucket. Plus he used the same restic password.
So this should clearly be something one should avoid. Because if one server is compromised, the attacker could access every other repo. So in a setup like this the data inside your restic configuration file should only allow you to access this single repo.
I guess everyone here is aware of that but still maybe it helps someone for his considerations.
1 Like
If you are the only person who knows the password what would happen if you are hit by a bus? Would anyone be able to restore files as necessary? Good backups for restoration should last longer than any individual in an organization. I do not know your specific situation, but various people that I have worked with have changed jobs, died of a heart attack, jay walked in front of a car. The backup need to survive those events.
1 Like
Well then make sure to include the key in your last will. Your children will thank you 
Honestly, if you’re a one person shop, print out your password db every six months and have your boss put it in their safe, along with the current disaster recovery handbook and offline backup hdds.
The earlier question “How to have an automated backup (with cron for example) without exposing my password to my colleagues and my boss (root) on a shared system?” implies it’s not a one person shop and that providing the password to the boss in unacceptable. If I was a suspicious person, I would think this indicates using corporate services to back up personal data; to back up corporate data with a password secret from the boss wouldn’t make sense.
1 Like