Confused about secure use of environment variables

Getting Help
1

Hi All. Restic looks just like what I’m after to do backups from Kubuntu to Backblaze B2, and kudos to the developers, but I am a bit confused about the right - and secure - way to use environment variables.

My understanding is that the B2 account ID and key are ‘secrets’ (presumably with them an attacker could modify or delete my backed up files - although presumably not access the unencrypted files without my restic password?).

The restic docs say to simply export these, but I’m worried I’ll forget to avoid including them in the bash history, and want to avoid typing them out each time.

The Quickstart Guide for Restic and Backblaze B2 Cloud Storage suggests putting the exports in a file in /etc/ and making the owner of that file root with appropriately secure file permissions, and using source to utilise the variables. However, I think this assumes running restic as root.

I guess I could add the environment variables to /etc/environment but then it’s permanently available to any user on the system, and I’m not sure how secure that is when I’m aiming to have the variables available to as limited a number of processes/users on my system as possible in case of hacks.

Searching on this forum or elsewhere comes up with many other subtly different methods

I don’t want or need to run restic as root since I’m only interested in backing up user files, and running restic mount as user means I can simply use Dolphin to navigate my backup.

I’m also not so worried about the password here, as I’m not planning to automate backups and so will enter the password manually, or from a secure key.

I may well be misunderstanding or overthinking the issue, but is there a best practice way of handling the environment variables securely and minimising the risk of them being available in places they shouldn’t be, and/or a way of storing the environment variables securley, where they can be safely loaded on an as-needed basis by a regular user running restic?

Thanks in advance, Ash.

2

I mean there are many ways to do this. How are you intending to handle the actual password needed for the repository? I presume you put that in a file or similar. Do the same with your environment variables. Such a file does not have to be a root one, if can be in your user’s regular files (assuming that is the one backing up your data). You’ll secure it using file permissions just like you would secure any other files on the system that you don’t want other users to be able to read.

3

I mean there are many ways to do this.

That’s the problem! I am looking for a best practice/most secure way of doing this when there are major differences between even the restic docs on using B2 and Backblaze’s own docs on using restic.

How are you intending to handle the actual password needed for the repository? I presume you put that in a file or similar. Do the same with your environment variables.

I mentioned this in my post - I will be typing it in manually or using a secure key, not using a password file. I can’t do that for the environment variables as restic doesn’t ‘ask’ for them when run.

Such a file does not have to be a root one, if can be in your user’s regular files

Of course, but as I mentioned, I’m not keen on having the environment variables available as plain text in user files. A minimal hack without any privilege escalation needed would mean these ‘secrets’ were trivially available.

As I said, I am hoping for a best-practice way of handling the environment variables securely so they don’t sit in the clear in user files and/or can be safely loaded on an as-needed basis by a regular user - using sudo if required - but with them available to the user’s shell temporarily so I can run restic as a user.

Thanks, Ash.

4

You can - simply write a script that when you run it asks for the relevant/sensitive values for the env var and sets that for the env var (the non-sensitive ones can be in the script or similar), so you are asked for both that and then the restic password. I’m not sure that key is something you can remember easily though?

It’s not required, but you could make a file that is accessible only to a privileged/root user and then create a sudo configuration entry such that the unprivileged user will only be able to read that specific file (and not do other root’y stuff). Then they would have to use sudo to get the B2 key and could put that in an env var (temporarily if you want, using a script), and also enter the restic password at a prompt.

5

Thanks, there are some useful starters there.

BTW, any pointers on a sudo command to load an environment variable for the user running the sudo command? My experiments trying that have all ended up with the environment variable only available to root.

Restic is great, but I guess it’s just a bit frustrating for me that there isn’t a straightforward way of setting it up securely that is clearly referred to in the docs - like, for example, rclone encrypting its config file.

6

User setups vary quiet a bit, so I guess it’s not easy or feasible to have documentation for each of those implementations.
The problem is to understand the way environments work and make your choices based on that.
The thing with environment variables are, that they are accessible for all processes and child processes of that user. So for some this might not be an issue where the environment variable is accessible to a logged in user. Some might want to use a dedicated user which backs up the data and where no login is possible at all (via a passwd entry with the /bin/nologin shell).
Some want to run it as root. This isn’t really a restic “issue” per se.

And I bet there are other options I’m not seeing right now. They are all valid.
I don’t want to start a discussion what is secure and what is not secure - your threat model might differ from my threat model so there is no value in pushing my threat model on to you or vice versa.

7

Not sure if this helps you, but see man sudoers for information on how you can specify sudo privileges that arent “all or nothing”, but rather limited to certain commands.

I’m sorry you’re struggling with setting things up the way you want. I think there’s more of a matter that you want this in a specific way that is way outside of the restic context (we simply cannot list a ton of different ways to run or set up restic, it’s just too many different use cases and too much detail, and no matter how much detail you put into it people will always ask for more, it’s simply not feasible, and especially so from a maintenance view). In the end it boils down to knowing how to use your operating system and stuff lie that, rather than the restic manual teaching people how to use e.g. Linux.

Also “securely” is pretty relative - I and a lot of people just run restic and enter our repository password, and we consider that secure enough. Some people in certain environments wouldn’t touch it with a stick unless there was asymmetric encryption. Some people just create a file with the password in on disk, and at best make sure it’s only readable by the user that actually runs the backups. Some like in your case need more than one credential for the backups to run and have to take additional steps to set that up the way they feel is secure.

Personally, to be honest with you, for my own machine I would just put that in a file accessible to my user only, since the bucket over at B2 is only used for backups and I still manually enter my repository password. You mentioned that “A minimal hack without any privilege escalation needed would mean these ‘secrets’ were trivially available”, which might be true, but I wonder what you are thinking about in this case?

1 Like
8

I apologise if my response came off as a bit ungrateful - that wasn’t the intention at all. Restic is a really nice bit of software and I appreciate the hard work that goes into developing, maintaining and supporting it. It’s also very easy to use, which belies the complexity under the surface. I also completely understand that any software project, let alone an open source one can’t support every possible user requirement.

I guess any frustration on my part is that I didn’t think my requirement was an unusual one - running as a user to back up user files to a cloud location while exposing my B2 ID and key as little as possible. However, I’m sure every user thinks their requirement is not an unusual one!

I have been a linux user for decades, but I don’t consider myself an expert. When it comes to security I know I don’t know enough, so I try and stick to things that I know will not land me in too much trouble - running as little as possible as root, and avoiding having ‘secrets’ in the clear on a user partition, for example.

However, Backblaze’s docs on restic suggest doing the former, and restic’s own docs suggests more the latter! I’m not saying this is wrong, or even necessarily insecure, just that it confuses me a bit!

Rclone, for example, puts the B2 key and ID in an encrypted config file. Again, I’m not saying that is right - just that rclone seems to mitigate to some degree risks to my ‘secrets’ that I take as someone with less system security knowledge than the application developers.

Anyway, thanks for the pointers - I shall spend some time getting to know sudo and environment variables a bit better!

1 Like
9

Oh, I have to say that I certainly did not think you seemed ungrateful :smiley: I also think it’s great that you are trying hard to make a well thought through decision with your setup. Keep asking more questions if you are still unsure, you’re very welcome to do so!

1 Like