Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update threat model #208

Open
fd0 opened this Issue Jun 30, 2015 · 10 comments

Comments

Projects
None yet
3 participants
@fd0
Copy link
Member

fd0 commented Jun 30, 2015

The threat model (section in doc/Design.md) should be updated to the latest structure, e.g. there is no id or version file any more.

Furthermore, remove implementation specific details from it as much as possible. A good example is https://pond.imperialviolet.org/threat.html

Clarify on when the local machine is trusted, e.g. only during backup or when the password is present.

@fd0 fd0 added the documentation label Jul 1, 2015

@MatthewVance

This comment has been minimized.

Copy link

MatthewVance commented May 17, 2016

When I have some time, I don't mind trying to revise the existing threat model. I'll need some more guidance though to make sure I'm covering it the right way. Also, the example link no longer works, but the Way Back machine has a snapshot of it at https://web.archive.org/web/20150913065100/https://pond.imperialviolet.org/threat.html.

@fd0

This comment has been minimized.

Copy link
Member Author

fd0 commented May 17, 2016

Oh, thanks for pointing this out. If you drop by at #restic on irc.freenode.net (if you use IRC) sometime in the evening, I'd be happy to discuss this. Thanks for the offer!

@MatthewVance

This comment has been minimized.

Copy link

MatthewVance commented May 18, 2016

I haven't had much free time today to get back to you so I just wanted to send this brief note to let you know I haven't forgotten. I don't typically use IRC, but don't mind jumping on one evening when I have some time. I'm not much of a coder, but like the work you're doing here so I wanted to offer to contribute in some small way.

@fd0

This comment has been minimized.

Copy link
Member Author

fd0 commented May 18, 2016

Heh, don't rush anything, the threat model will be here tomorrow. I've just realized that we don't live in the same timezone, so "in the evening" is probably something else for you. We can also discuss the threat model in this issue (or have a PR or something else).

@MatthewVance

This comment has been minimized.

Copy link

MatthewVance commented May 25, 2016

Thanks. I haven't forgotten about this. I've started drafting something, but it'll take me a bit longer to finish the initial draft up. I'll share some of the ideas here before submitting a pull request.

@MatthewVance

This comment has been minimized.

Copy link

MatthewVance commented Jun 4, 2016

Right now, I'm thinking the following are among the threats I need to address:

  • Physical access
  • Network access (local and/or remote)
  • Malware
  • Weak passwords
  • Advances in cryptography or computing yields underlying crypto algorithm broken

Please let me know if you think I should add or remove any.

Below is a rough draft of what I have thus far (it doesn't touch on all the above yet). I wanted to go ahead and share it to see if it is along the lines of what you have in mind.

An attacker with access to your backup storage location could:

  • Delete or manipulate your backups, thereby impairing your ability to restore files from the comprised storage location.
  • Attempt a brute force password guessing attack against a copy of the repository.

An adversary who can passively monitor all Internet traffic could:

  • Defer where you are storing your remote backups via http headers (URLs).
  • Defer from where you create your backups (i.e., the location where the requests originate).

An attacker who compromises (vial malware, physical access, etc.) the host system making backups could:

  • Render the entire backup process untrustworthy (e.g., intercept password, copy files, manipulate data).
@fd0

This comment has been minimized.

Copy link
Member Author

fd0 commented Sep 12, 2016

There's another thing that came up in a discussion on IRC with @viric the last couple of days: I've added an experimental local cache (see PR #607). We agreed that the cache should be encrypted (at least by default), so that no metadata leaks e.g. when encrypted filesystems are mounted.

This is a temporal perspective: What if attackers gain access to the user's machine or home directory some time after the backup was completed? Especially what happens when the users didn't store the password anywhere (so the attackers are unable to decrypt anything from the repo)?

@MatthewVance

This comment has been minimized.

Copy link

MatthewVance commented Aug 31, 2017

@FiloSottile mentioned a couple of items in his recent blog post that could be good additions to the threat model. Here's a couple that stood out to me:

attacker-supplied data can lead to straightforward fingerprinting attacks on any kind of deduplicated system. (This should have been in the threat model.)

I imagine file/backup sizes are not protected, but it's not mentioned.

@colans

This comment has been minimized.

Copy link

colans commented Aug 28, 2018

I just noticed:

The host system a backup is created on is trusted. This is the most basic requirement, and essential for creating trustworthy backups.

Should we say anything about how integrity of the backups can be maintained even if the host does get compromised (with the rclone serve restic + SSH forced command set-up)?

@fd0

This comment has been minimized.

Copy link
Member Author

fd0 commented Aug 28, 2018

That's not an easy thing to add. Attackers with the ability to add data to the repo (but not remove something) could still upload pack files with wrong headers. For example, the header says that the file contains the blob with a specific hash, but that's not really the case. I'm not sure what the implications are right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.