Skip to content

Security of the personal files (user data) on the computer (backups)

EU OS should offer an approach to support the security of the personal files of the EU OS computer users (user data).

Goals

Confidentiality

  • mostly provided by overall security measures of the computers, such as secure boot, verified boot through signatures and hashes (see: https://www.youtube.com/watch?v=D7HqckeHlx8)
  • optionally: full disk encryption either locked to the TPM or to a FIDO2 token (e.g. yubikey)

Integrity

  • snapshots (local and remote)
  • strong user authentication (FIDO2 token, secure password)

Availability (Protection against loss)

  • snapshots (local and remote)

Efficiency

Most of the measures have a performance impact that scales linearly with the amount of the data to protect. Hence, the approach should offer means to exclude certain data from protection: data that can be easily retrieved again from somewhere else or that can be re-generated (browsing cache of Firefox, KDE Baloo full-text search index). Data should be markable for exclusion by:

Implementation

Most likely, EU OS computers should use btrfs for system and user data partitions. Btrfs is a popular choice with major Linux distributions such as Fedora and openSUSE.

The choice of the implementation depends pretty much also on the local requirements and integration in other systems. If for instance the latest user data is kept on Nextcloud or in a separate storage readily available for use from a virtual desktop environment (VDI), additional constraints may lead to different design choices.

Note that all implementations should assume that computers may be powered off any time, have occasionally no network access and may be only in home/public wifi.

btrfsbk

website: https://digint.ch/btrbk/ repo: https://github.com/digint/btrbk latest release: march 2023 😟 latest commit: 1 month ago (6 of July at the time of writing) 👁️

btrfsbk allows with a simple config file to determine the frequency and retention periods of copy-on-write btrfs snapshots and their transfer to a remote btrfs filestorage.

According to the website, the tool is robust against interruptions of the transfer.

Example config:

snapshot_preserve_min   2d
snapshot_preserve      14d

target_preserve_min    no
target_preserve        20d 10w *m

snapshot_dir           btrbk_snapshots

volume /mnt/btr_pool
  target /mnt/btr_backup/mylaptop
  target ssh://backup.server.local/mnt/btr_backup/computer_id_39abc3f
  subvolume home
  [...]

Such a system of snapshots would allow users to recover accidentally removed or deleted files from their own device.

Replicating snapshots to the server would offer a remote backup. To use this data from within the virtual desktop environment (on another device), one would need to ensure that a snapshot is transferred in short intervals or before logging out/powering of the device. As this is difficult to achieve, it may be more advisable to offer different approaches for different folders/files. Folders with current working files may be synced via Nextcloud, which offers a nearly instantaneous sync.

It is unclear if btrbk sync scales well when hundreds or thousands sync in parallel. As btrbk relies on btrfs snapshots of btrfs subvolumes, it does not offer exclusion by pattern matching or tags.

Borg and Borgmatic

Borg has a huge community and is used in many production setup it seems. While btrfsbk assumes on the destination also a btrfs file storage, Borgmatic and Borg offer a different approach:

  1. borgmatic organises local snapshots that offer users easy access (similar to https://github.com/openSUSE/snapper and btrfsbk)
  2. borgmatic relies on borg to send snapshots to a remote repository (respecting pattern matching)

Unlike btrfsbk archives that are just remote btrfs subvolumes and can be mounted in a VDI, borg archives do not permit easy access or checkout of files.

Nextcloud

This is the cheap and simple approach: All users get their $HOME/Documents folder synced via Nextcloud client running on their device. This allows the users to find their latest files via Nextcloud in the browser (if made available) or in a VDI that also syncs Nextcloud files to a Documents folders.

Nextcloud offers to store files on S3, which many organisations already have.

Application-Specific Backups

In some cases, employing existing application-specific backups may offer better features/reliability. Examples:

Monitoring

Whatever the device is doing locally in terms of snapshotting/remote backups, it would be good to log this into a facts file, where it can become part of status reports in foreman.

Issues

  • configuration data may need to be backuped and rolled back in case that the entire system is rolled back (see #40)
  • configuration data of applications is stored at several places:
    • ~/.local/config for applications installed in the image (such as KDE Plasma, Dolphin file browser, etc.
    • ~/.var/app/my_app_name/config for flatpaks (here: flatpak my_app_name)

References

Edited by Robert Riemann