Relax-and-Recover (ReaR) is a disaster recovery and system migration tool. This document describes the security architecture of ReaR and how it protects your data and systems.
In general, ReaR is designed to be secure by default. It does not expose any services or ports to the network. As ReaR is a disaster recovery tool, it requires full access to the system and its data. This means that ReaR must be run as root user. Otherwise ReaR won’t be able to perform its core functions. Also, ReaR makes extensive use of low level system tools (e.g. to analyse the system and capture the system state) so that it is not feasible to run ReaR as unprivileged user. During the actual recovery, ReaR is the system and runs as primary process on the recovery system. This is why ReaR must be run as root user also during recovery, where it must partition the disks, format the filesystems, install the bootloader, etc.
Given this context, there are still several security measures in place that aim to protect your data and systems. The following sections describe these measures in more detail.
The ReaR Maintainers own the security of the ReaR software. This means that the ReaR Maintainers are responsible for ensuring that the ReaR software is secure and that it follows best practices for security. The ReaR Maintainers are also responsible for responding to security incidents and vulnerabilities in the ReaR software. If you discover a security vulnerability in ReaR, please report it to the ReaR Maintainers via our support options.
Specifically, we own the security of:
For these we will do our best to ensure that there are no security issues and that the software is secure. We will also respond to security incidents and vulnerabilities and fix them as soon as possible. For other means of distributing ReaR packages or source code we unfortunately cannot feel responsible as they are outside of our control.
ReaR follows the shared responsibility model. This means that ReaR is responsible for the security of the ReaR software itself, while the user is responsible for the security of the data and systems that ReaR interacts with. This includes the data that ReaR backs up and restores, as well as the systems that ReaR runs on. The user is especially responsible for safeguarding the ReaR configuration files against potential attacks, see below. Furthermore, the user is responsible for the security of the rescue media that ReaR creates. The biggest attack vector in the context of using ReaR is actually manipulating the rescue media. If an attacker can manipulate the rescue media, they can easily compromise the system that is being recovered. This is why it is important to protect the rescue media and ensure that it is only accessible to authorized users and only when actually needed.
To help our users protecting their systems, by default the ReaR rescue media does not contain secrets. This means that the rescue media does not contain any sensitive information like passwords, encryption keys, etc. This is a conscious design decision to reduce the attack surface of the rescue media. If you need to recover a system that requires secrets, you must by default provide these secrets manually during the recovery process. This ensures that the secrets are not stored on the rescue media and are only available when actually needed. However, to facilitate automated disaster recovery, ReaR can be configured to include secrets in the rescue media. This is a trade-off between security and convenience. If you choose to include secrets in the rescue media, you must take extra care and ensure that the rescue media is protected accordingly.
ReaR protects secrets in configuration variables, so that they are not exposed in the (debug) logs. The --expose-secrets option can be used to expose secrets in the logs for debugging purposes. This option is disabled by default.
To facilitate protecting secrets even from verbose tracing of the Bash scripts (set -x), it is important to wrap statements that handle secrets like this:
# set a variable with a secret
{ VAR='secret_value' ; } 2>>/dev/$SECRET_OUTPUT_DEV
# use the variable with the secret
{ COMMAND $SECRET_ARGUMENT ; } 2>>/dev/$SECRET_OUTPUT_DEV
NOTE: These are our ideas, the implementation will follow step by step with the next major release 3.0. This section will be updated accordingly. See issues 3258, 3259, 3203 and 3171 for more details.
ReaR is written in the Bash scripting language, the configuration is actually Bash script code and the ReaR system architecture is designed for easily extending ReaR functionality via dropping shell scripts into the ReaR script directories. Therefore the ReaR code is by nature more open than close, which is - from a security perspective - a trade-off for convenience and extensibility over security.
We differentiate between the following scenarios for potential code injections:
/etc/os-releasesudo make install--portable) or from a source checkout/etc/rear or provided via the -C optionTo mitigate the risk of code injections, the following checks are implemented:
source as we must also support the different quoting styles that can be used there. This is considered safe, as the operating system configuration files are under the control of the operating system vendor and are not writable by unprivileged users.source. Instead, we use grep or other tools to extract the required information. This is considered safe, as the configuration files are not executed as code.root and are not writable by unprivileged users or that the scripts are sourced from the ReaR scripts paths. This is considered safe, as normally the ReaR scripts are under the control of the ReaR package and are not writable by unprivileged users. If ReaR is run from a remote file system then the security of ReaR depends on the security of the remote file system.Unfortunately, when running ReaR from a source checkout or in portable mode, we cannot implement further safeguards without compromising on core ReaR functionality. This is a trade-off between security and usability in favour of ReaR doing its designated job. If you run ReaR from a source checkout or in portable mode, you must take extra care and ensure that the ReaR scripts and configuration files are protected accordingly.
The ReaR configuration is executable Bash code and this is an important feature to facilitate dynamic configuration. Therefore we cannot implement further checks or limits on the ReaR configuration files, but rely on the ReaR user to protect the configuration files accordingly.