Data persistence is a somewhat tricky topic in a Live system context, especially one explicitly designed to avoid leaving any trace of its use.

Some real-life usecases however require to set up some kind of data persistence, which were then carefully introduced and supported.

  1. Usecases
    1. What can be made persistent?
      1. Application-specific configurations
      2. User data store
      3. Additional software packages
    2. Persistence storage location
  2. Specifications
  3. Current state of things
  4. Implementation
    1. Backend
      1. Example
    2. User interface
      1. bootstrap persistent storage
        1. Design
      2. Configure which bits are persistent
        1. Design
      3. Unlock the Persistent Storage at boot time
        1. Design
    3. backend / tails-greeter interface
      1. Long story short
      2. Interfacing
      3. Possibly valid Persistent Storages
      4. Asking live-persist to set up persistence
    4. Additional software packages
    5. Security
    6. Migration from pre-0.21 Persistent Storage
      1. Tails
      2. Support
      3. Contribute
      4. About us
      5. News

Usecases

What can be made persistent?

Here are the usecases that are of interest for our users and we want to support.

Application-specific configurations

This is relevant for the following applications:

  • GnuPG, SSH and OTR key pairs
  • GnuPG configuration
  • SSH client configuration
  • Tor Browser certificate trust
  • Tor Browser bookmarks
  • Pidgin configuration
  • MUA configuration
  • printers configuration
  • Tor's data/cache for faster bootstrap with slow connections and better protections through more stable entry guards (/var/lib/tor/)
  • NoScript global behaviour (whitelist / blacklist) and exceptions

A tool (tails-persistence-setup) helps the user to choose exactly what files/directories should be persistent. With such a general solution the above things don't have to be implemented individually, and are instead present as default suggestions in the tool, and advanced users with uncommon requirements can do whatever they want so we don't hear them nagging all the time.

Stuff we don't want to actively support making persistent:

  • web browser addons (while we don't want to make it impossible to install addons, we think it's a really bad idea, and won't actively support it, since it partitions the Tails users anonymity set, thus having bad consequences both on people who do it and on others)

User data store

A persistent non-home data store for whatever random files the user wants to have persistent. This is the ~/Persistent/ directory.

Additional software packages

If a user needs software that is not included in Tails by default it can be quite annoying to fetch the APT information and download it (slow over Tor) every time. Therefore, APT packages lists and cache can easily be made persistent. It's also possible to store in the Persistent Storage a list of additional software packages to be automatically reinstalled on boot.

Persistence storage location

The Tails Persistent Storage is a LUKS-encrypted GPT partition, labeled TailsData, stored on a removable storage device.

Specifications

Once a Persistent Storage is enabled, changes to persistent files are saved.

Moreover:

  • Read-write access to the Persistent Storage is not the default: it requires a voluntary user action such as unlocking the Persistent Storage in the Welcome Screen.
  • The Persistent Storage uses strong, well-known, Free Software, peer-reviewed encryption tools (dm-crypt and LUKS)
  • Fixed storage devices are be blacklisted by default from the search for a Persistent Storage. Rationale: preventing the risk of using a malicious Persistent Storage seems more important than supporting the rare "I want to store my Persistent Storage on a fixed hard-disk" use-case.

Current state of things

Tails 0.11 and greater supports the persistent application-specific configurations and persistent user data store usecases.

Implementation

Backend

Debian Live already supports several kinds of persistence, including snapshots of selected files and persistence store automounting, both at the $HOME and system-wide levels. LUKS persistent volumes are supported.

Neither home automounting nor live-snapshot currently fit the application-specific configuration persistence use case. Both because they are not finely grained enough and persist too much.

That's why we have decided to:

  • generalize overlays (*-rw) to handle arbitrary directories, not just / and /home,
  • add a "linkfiles" (inspired by Joey Hess' dircombine) option to create symlinks from the root of a non-persistent directory (e.g. $HOME) to regular files stored in a persistent location (e.g. .gitconfig, .vimrc, etc.)

The code we ship lives in our live-boot Git repository.

Example

Example live.persist configuration file:

# destination       options
/var/cache/apt
/home/amnesia       linkfiles,source=dotfiles

This will result in:

  • $MEDIA/apt is bind-mounted onto /var/cache/apt
  • /home/amnesia/ contains symlinks to every file in $MEDIA/dotfiles

User interface

bootstrap persistent storage

A Configure persistent storage menu entry is the entry point to the bootstrap persistent storage UI. This UI allows the user to set up a Persistent Storage in the free space left on the USB stick by Tails Installer.

Choosing persistence is something activelly opt-in, i.e. "I want this, I read the documentation for related information, then run the setup tool", rather than something we throw to the face of every user who did not think of it herself.

This UI is called tails-persistence-setup and its code lives in its own Git (gbp-style) repository.

Design

Setting up a Persistent Storage means:

  • detect the device Tails is running from
  • error out if not running from USB
  • error out unless Tails was installed using Tails Installer (i.e. unless it's running from a GPT partition labeled Tails)
  • error out if the device Tails is running from already has a Persistent Storage
  • ask the user an encryption passphrase (welcome bonus: pointing to the relevant documentation about choosing a strong passphrase)
  • create a LUKS-encrypted partition on the Tails USB stick
    • uses all the free space left by Tails Installer
    • labeled TailsData
    • create a filesystem in the encrypted container
    • give ownership on the filesystem to the default Tails user

  • explain the user how/when/why to run the configure which bits are persistent UI

  • How/when to run? Initially, we wanted to do so on first boot. However, to detect if a given Tails system is booting for the first time or not, every first boot must change something on the Tails system partition. We don't want to do this, hence the tails-persistence-setup will be run from the Applications menu by users who decide they want a Persistent Storage.

  • Storage location: To keep the GUI and documentation simple, we only support setting up a Persistent Storage on the USB stick Tails is running from. Note: the underlying tools (live-boot backend, tails-greeter) will support storage on whatever relevant device, though; moreover, tails-persistence-setup actually knows how to set up a Persistent Storage on arbitrary devices, thanks to command-line options. Therefore, brave and advanced users can prepare their store their persistent data wherever they want, but this is not something we will actively support and document beyond the bare minimum (--help and manpage).

  • Filesystem to create on the encrypted storage container: ext3 looks like the safe bet. The default ext3 journalling mode only journals metadata, not data, so the impact of journalling on Flash drives should be pretty minor. Also, we could not find a Flash file system with mature enough support for block devices: they are rather targeted at raw access to MTD devices.

  • Integration with other configuration steps: it seems doable to have tails-persistence-setup host both the bootstrap persistent storage and configure which bits are persistent user interfaces in a wizard-like way. The current code provides the foundations to do so, and the menu entry is called Configure persistent storage. One may call it using multiple --step options, and the UI will present every step sequentially; currently, the only implemented steps are bootstrap, configure (that implements the configure which bits are persistent UI) and delete.

  • Programming language: written in Perl, i.e. the language the one of us who wrote it is the most efficient at.

  • Partition / filesystem / LUKS management is done using udisks; the udisks bug wrt. partition attributes is workaround'ed.

Configure which bits are persistent

This is automatically run right after the Persistent Storage bootstrap step. The user is enabled to change the configuration later. Changes to the Persistent Storage settings are taken into account at next boot.

Design

  • either the Persistent Storage is currently unlocked in read-write mode, and thus the persistence partition is already mounted; or the user is directly coming from bootstrap, and then we must mount the partition ourselves
  • by default, set up a linkfiles-enabled persistent ${HOME}/dotfiles, preconfigured to have its contents symlinked into $HOME.
  • apart of this, let's consider non-directories persistence an advanced feature: to start with, and possibly forever, this could only be configured by manually editing live-persist file
  • a few presets are made available (e.g. ~/.gnupg/); technically, each of these has a name, optionally a short description and icon, and the needed information to make a simple directory persistent (e.g. make /home/amnesia/.gnupg persist, as the "gnupg" sub-directory of the persistent volume). The GUI displays every available preset, along with its current (enabled/disabled) status and available details (description, icon). tails-persistence-setup has means to merge its presets list with the configuration read from the input configuration file; to this end, it knows if a given preset is enabled in the input configuration file;
  • by default, the current configuration is displayed as a list of items (= config lines); listed items may be toggled on/off; an Add custom button allows to enter custom source, destination (and comma-separated list of options?)

Unlock the Persistent Storage at boot time

Choosing between various persistence modes is one of the reasons why we've written a graphical boot menu: the Welcome Screen (aka. tails-greeter).

Design

  • asks whether to unlock the Persistent Storage at all;
  • ask list of possibly valid Persistent Storages to live-persist
  • initial implementation (MVC -speak): the model (live-persist and tails-greeter code that runs it) supports enabling multiple Persistent Storages, but the view (tails-greeter GUI) only supports one Persistent Storage
  • ask LUKS passphrase, deals with errors
  • for a given Persistent Storage, it's all or nothing: all bits of persistence configured in its live.persist are to be set up
  • runs live-persist to set up persistent data where it belong
  • pass information to the user session (at least tails-persistence-setup needs information) through shell variables set in /var/lib/gdm3/settings/tails.*

backend / tails-greeter interface

Long story short

  1. The user chooses to unlock the Persistent Storage in the Welcome Screen, aka. tails-greeter.
  2. tails-greeter asks live-boot the list of possibly valid Persistent Storages.
  3. For each such volume, tails-greeter asks the user to enter the passphrase or to skip it, and tries to unlock. tails-greeter deals with error catching, retrying, etc. as appropriate.
  4. tails-greeter asks live-boot to set up persistence (at least custom mounts and linkfiles), passing it the list of volumes that were successfully unlocked.

Interfacing

A live-persist script shall be written, implementing each kind of tails-greeter to live-boot communication as a sub-command, such as:

live-persist [OPTIONS] list [LABEL]...
live-persist [OPTIONS] activate VOLUME...

live-persist will report success and failure as any other well-behaved synchronously-called shell script, that is: with appropriate exit codes and STDERR.

Possibly valid Persistent Storages

In our case, that is quite simple: it means removable LUKS encrypted filesystem, stored on GPT partitions labeled Tails-persistence (or similar, must be decided upon taking into account technical restrictions such as what GPT supports).

This means we need to:

  • make sure we can pass this desired label to live-boot, probably on the kernel command-line along with other parameters

In other (non-GPT) usecases, generally, it would be filesystems labeled with live-rw or home-rw, but if they're on encrypted device, then live-boot has to unlock the parent device them to see the label; also, in non-Tails usecases, any encrypted filesystem may contain a *-rw file, and must be unlocked to know too; so any encrypted device may be a valid Persistent Storage that is worth passing to tails-greeter; . live-persist will support non-Tails usecases on a best-effort basis, leaving room for improvement in case other developers want to add support for their preferred usecases.

Asking live-persist to set up persistence

To start with, we've factored out only the custom mounts part from the main live-boot script; it depends on factoring out other kinds of persistence (e.g. all types of unionfs-style filesystems) first.

Additional software packages

The tails-additional-software script installs a list of additional software packages stored in the Persistent Storage. For details see additional software packages.

Security

The root directory of the Persistent Storage is created by the persistence configuration assistant, owned by root:root, with permissions 0770. It is group-writable so that we can grant write access to other users with ACLs.

Additionally, ACLs grant, on this directory:

  • full (rwx) access to the tails-persistence-setup user, so that it can edit the persistence configuration;
  • search (x) access to the amnesia user, so that it can follow the symlinks generated by the dotfiles feature.

The persistence configuration assistant is run with password-less sudo as the tails-persistence-setup dedicated user. It creates and updates a configuration file called persistence.conf, that is owned by tails-persistence-setup:tails-persistence-setup, with permissions 0600 and no ACLs. It refuses to read configuration files with different permissions.

live-persist checks these permissions on the root directory of the Persistent Storage, on persistence.conf and on live-additional-software.conf. Then, live-persist disables every such file, and refuses to set up any feature of the Persistent Storage, if the Persistent Storage has wrong permissions. It also disables every such file that has wrong permissions itself.

Migration from pre-0.21 Persistent Storage

Before Tails 0.21, the Persistent Storage and its configuration file had weaker permissions. An attacker who could run arbitrary code as the desktop amnesia user could tamper with the persistence configuration, and — with some minimal amount of imagination — give themselves persistent root credentials, etc.

A migration process, available in Tails 0.21, allowed users to move to the new setup relatively safely and (in most cases) very easily. This migration code was removed in Tails 0.22.

Still, after login, if some settings are found that were not fully migrated, or never migrated at all (i.e. if live-additional-software.conf.disabled, live-persistence.conf or live-persistence.conf.old is found), a desktop notification makes the user aware of it, and points them to the migration documentation so that they can learn how to migrate their configuration.