EU OS

Appearance

User Data Management ​

WARNING

This page is work in progress. Related issue: #46

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)

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 ​

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 accidently 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 transfered in short intervalls or before logging out/powering of the device. As this is difficult to achieve, it may be more advisible 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 btrfs snapshots do not support individual exclusion lists, files for exclusion must be put in specfic folders in a subvolume that is not synced. Think of ~/.local/share/containers/storage/overlay, which contains podman/toolbox image data and does not need to be backed up. Other examples may be the browser cache ~/.mozilla/firefox/random-profile-string/storage/default, the KDE search index baloo /home/rriemann/.local/share/baloo.

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 have already.

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)