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

Adds option to restore from backup file already on server. #5909

Merged
merged 1 commit into from
Jun 9, 2021

Conversation

zenmonkeykstop
Copy link
Contributor

@zenmonkeykstop zenmonkeykstop commented Apr 21, 2021

Status

Ready for review

Description of Changes

Fixes #5906 .

when the --no-transfer argument is used with ./securedrop-admin restore,
instead of transferring the backup tarball to the Application Server, the
local copy of the tarball will be compared with an expected remote file of the
same name in /tmp on the server. If checksums match, the remote copy will be
used to perform the backup.

This is intended to address cases where backups are too large to reliably
transmit over Tor via the Ansible synchronize module. Instead, backups can be
copied to the server using rsync, or via an encrypted transfer USB.

Testing

  • Acquire some backup files (one v2-only (v2-only.tar.gz), one v2+v3(v2nv3.tar.gz))

  • Set up a prod Focal instance

  • switch to this branch on the admin workstation

  • copy the backup files to the ad admin home directory on the app server

  • on the app server: sudo cp v2nv3.tar.gz /tmp/v2-only.tar.gz

  • on the admin workstation: ./securedrop-admin --force restore --preserve-tor-config --no-transfer install_files/ansible-base/v2-only.tar.gz

    • confirm that the restore process quits with a message about a checksum mismatch without performing any server-side steps.
  • on the app server: sudo cp v2-only.tar.gz /tmp/

  • on the admin workstation: ./securedrop-admin --force restore --preserve-tor-config --no-transfer install_files/ansible-base/v2-only.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does not run.
  • on the app server: sudo rm /tmp/v2-only.tar.gz

  • on the admin workstation: ./securedrop-admin --force restore --preserve-tor-config install_files/ansible-base/v2-only.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does run.
  • on the app server: sudo cp v2-only.tar.gz /tmp/v2nv3.tar.gz

  • on the admin workstation: ./securedrop-admin --force restore --no-transfer install_files/ansible-base/v2nv3.tar.gz

    • confirm that the restore process quits with a message about a checksum mismatch without performing any server-side steps.
  • on the app server: sudo cp v2nv3.tar.gz /tmp/

  • on the admin workstation: ./securedrop-admin --force restore --no-transfer install_files/ansible-base/v2nv3.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does not run.
  • on the app server: sudo rm /tmp/v2nv3.tar.gz

  • on the admin workstation: ./securedrop-admin --force restore --no-transfer install_files/ansible-base/v2nv3.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does run.
  • for extra points, try playing around with other backup files - take chances, make mistakes, get messy!

Deployment

Deployed with admin workstaiton update

Checklist

If you made changes to securedrop-admin:

  • Linting and tests (make -C admin test) pass in the admin development container

If you made non-trivial code changes:

  • I have written a test plan and validated it for this PR

Choose one of the following:

  • I have opened a PR in the docs repo for these changes, or will do so later
  • I would appreciate help with the documentation
  • These changes do not require documentation

when the '--no-transfer' argument is used with `./securedrop-admin restore`,
instead of transferring the backup tarball to the Application Server, the
local copy of the tarball will be compared with an expected remote file of the
same name in `/tmp` on the server. If checksums match, the remote copy will be
used to perform the backup.

This is intended to address cases where backups are too large to reliably
transmit over Tor via the Ansible synchronize module. Instead, backups can be
copied to the server using rsync, or via an encrypted transfer USB.
@zenmonkeykstop zenmonkeykstop force-pushed the 5906-restore-manual-transfer branch from 5ebe435 to 68c86bb Compare April 23, 2021 18:36
@zenmonkeykstop zenmonkeykstop marked this pull request as ready for review April 23, 2021 19:04
@zenmonkeykstop zenmonkeykstop requested a review from a team as a code owner April 23, 2021 19:04

- name: Calculate remote backup file checksum
stat:
path: "/tmp/{{ restore_file }}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about allowing a full path, to allow for /tmp on the server not having enough free space?

Copy link
Contributor Author

@zenmonkeykstop zenmonkeykstop Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not in favour of it - points against:

  • The SD setup instructions as they stand don't result in a separate /tmp partition, so if there's enough space on / this isn't an issue - and the backup job would have failed in the first place as it also uses /tmp
  • this is the current backup location - it would introduce more changes and would require extra work to make sure backup tempfiles are purged from whatever alternate location was specified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, writing sensitive files to /tmp is not recommended [1], due to the permissions of that partition, and the ability of all system users to write to it. In this case, the servers are effectively single-user systems, so the risks are relatively low, but in the case where an attacker has unprivileged access to the system, they may have access to more information.

[1] some links/references in https://security.openstack.org/guidelines/dg_using-temporary-files-securely.html

@eloquence eloquence added this to the 2.0.0 milestone May 4, 2021
@eloquence eloquence modified the milestones: 2.0.0, 2.1.0 May 20, 2021
@kushaldas kushaldas self-assigned this Jun 2, 2021
Copy link
Contributor

@kushaldas kushaldas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following steps failed:

  • on the app server: sudo cp v2nv3.tar.gz /tmp/
  • on the admin workstation: ./securedrop-admin --force restore --no-transfer install_files/ansible-base/v2nv3.tar.gz
    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does not run.
  • on the app server: sudo rm /tmp/v2nv3.tar.gz
  • on the admin workstation: ./securedrop-admin --force restore --no-transfer install_files/ansible-base/v2nv3.tar.gz
    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does run.

The error message:

TASK [restore : Verify that local and remote backup file checksums match] **************************************
fatal: [app]: FAILED! => {}

MSG:

The conditional check 'remote_backup_file.stat.checksum == local_backup_file.stat.checksum' failed. The error was: error while evaluating conditional (remote_backup_file.stat.checksum == local_backup_file.stat.checksum): 'dict object' has no attribute 'checksum'

NO MORE HOSTS LEFT *********************************************************************************************

NO MORE HOSTS LEFT *********************************************************************************************

PLAY RECAP *****************************************************************************************************
app                        : ok=10   changed=6    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   


@kushaldas
Copy link
Contributor

I guess the test step is wrong, -no-transfer should not be there in the command for that final test.

Copy link
Contributor

@kushaldas kushaldas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested with

  • on the admin workstation: ./securedrop-admin --force restore --preserve-tor-config --no-transfer install_files/ansible-base/v2-only.tar.gz

    • confirm that the restore process quits with a message about a checksum mismatch without performing any server-side steps.
  • on the app server: sudo cp v2-only.tar.gz /tmp/

  • on the admin workstation: ./securedrop-admin --force restore --preserve-tor-config --no-transfer install_files/ansible-base/v2-only.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does not run.
  • on the app server: sudo rm /tmp/v2-only.tar.gz

  • on the admin workstation: ./securedrop-admin --force restore --preserve-tor-config install_files/ansible-base/v2-only.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does run.
  • on the app server: sudo cp v2-only.tar.gz /tmp/v2nv3.tar.gz

  • on the admin workstation: ./securedrop-admin --force restore --no-transfer install_files/ansible-base/v2nv3.tar.gz

    • confirm that the restore process quits with a message about a checksum mismatch without performing any server-side steps.
  • on the app server: sudo cp v2nv3.tar.gz /tmp/

  • on the admin workstation: ./securedrop-admin --force restore --no-transfer install_files/ansible-base/v2nv3.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does not run.
  • on the app server: sudo rm /tmp/v2nv3.tar.gz

  • on the admin workstation: ./securedrop-admin --force restore install_files/ansible-base/v2nv3.tar.gz

    • confirm that the restore process completes sucessfully, and that the task to transfer the tarball does run.

I am okay to merge this. Will do so after the standup.

@zenmonkeykstop zenmonkeykstop merged commit 1ac642f into develop Jun 9, 2021
@rmol rmol deleted the 5906-restore-manual-transfer branch June 23, 2021 13:51
@cfm cfm mentioned this pull request Oct 8, 2021
26 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support restoring from a backup file that has been manually transferred to the server?
5 participants