#3345 PR merged
: Make sourcing DUPLY_PROFILE reasonably secure¶
Labels: enhancement
, bug
, cleanup
, fixed / solved / done
,
critical / security / legal
jsmeix opened issue at 2024-11-20 14:19:¶
-
Type: Bug Fix / Security Enhancement
-
Impact: Critical
"Relatively" critical impact for two reasons:
It is a required security enhancement and
it is a backward incompatible change.
It is only "relatively" critical because
it is only when BACKUP=DUPLICITY is used
so it is not a backward incompatible change
that hits all or a lot of users.
-
Reference to related issue (URL):
https://github.com/rear/rear/issues/3293
https://github.com/rear/rear/issues/3259 -
How was this pull request tested?
Cannot test it because I neither use duplicity nor duply. -
Description of the changes in this pull request:
Overhauled prep/DUPLICITY/default/200_find_duply_profile.sh
so that now only an explicitly user specified DUPLY_PROFILE
will get sourced to avoid that some automatism
finds and sources whatever it may have found.
Error out when DUPLY_PROFILE is empty or does not exist
to make the user aware that he must explicitly specify
his correct DUPLY_PROFILE.
jsmeix commented at 2024-11-20 14:22:¶
Next steps within this pull request
(to keep together what belongs together)
are:
Removal of the find_duply_profile function call in
restore/DUPLICITY/default/110_check_temp_dir_with_duply.sh
Removal of the find_duply_profile function
from lib/global-functions.sh:function
Change the DUPLY_PROFILE description in default.conf
jsmeix commented at 2024-11-20 17:40:¶
Tomorrow I will try to test it in a generic way
even without having duplicity or duply installed
e.g. by things like using artificial placeholder
programs for duplicity and/or duply (e.g. /bin/true)
so that I could only see in the ReaR log file
(with debugscript mode) if my changed scripts
seem to work as intended.
jsmeix commented at 2024-11-21 10:03:¶
With using /usr/bin/true as artificial placeholder program
for duplicity and duply and python
"rear -D mkrescue" finishes for me without error
with this etc/rear/local.conf
OUTPUT=ISO
BACKUP=DUPLICITY
DUPLY_PROFILE="/root/qqqq/duply.profile"
BACKUP_URL=file:///other/
BACKUP_ONLY_INCLUDE="yes"
BACKUP_PROG_INCLUDE=( /home/tux )
{ SSH_ROOT_PASSWORD='rear' ; } 2>>/dev/$SECRET_OUTPUT_DEV
USE_DHCLIENT="yes"
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="5"
and this /root/qqqq/duply.profile
GPG_KEY='BD4A8DCC'
GPG_PW='my_secret_key_phrase'
TARGET='scp://root:my_secret_password@freedom//exports/archives/ubuntu-15-04'
SOURCE='/'
MAX_AGE=1M
MAX_FULL_BACKUPS=1
MAX_FULLS_WITH_INCRS=1
VERBOSITY=5
TEMP_DIR=/tmp
from
https://www.it3.be/2015/09/02/rear-using-duply/
jsmeix commented at 2024-11-21 10:06:¶
While testing I found out that the DUPLY_PROFILE
is not included in the ReaR recovery system
and I wonder how it ever was included
because I see nowhere in the old DUPLICITY code
(i.e. the DUPLICITY code without my changes here)
that it could be included:
# for f in $( find usr/sbin/rear usr/share/rear/ -type f | grep DUPLICITY ) ; do grep COPY_AS_IS $f ; done
COPY_AS_IS+=( /etc/fuse.conf )
COPY_AS_IS+=(
[ "x$SKRIPT_FILES" != "x" ] && COPY_AS_IS+=( "$SKRIPT_FILES" )
jsmeix commented at 2024-11-21 12:32:¶
Tested again "rear -D mkrescue" plus "rear -D mkbackuponly"
with latest changes here on a test VM
which both finished for me without error
with this etc/rear/local.conf
OUTPUT=ISO
OUTPUT_URL=nfs://192.168.178.66/nfs
BACKUP=DUPLICITY
DUPLY_PROFILE="/root/qqqq/duply.profile"
...
and again /usr/bin/true as placeholder program
for duplicity and duply and python
and same /root/qqqq/duply.profile as above.
Then I booted on another test VM
the ReaR recovery system ISO
and did "rear -D recover"
which also worked for me without error
up to and including the point of the backup restore
with restore/DUPLICITY/default/150_restore_duply.sh
i.e. via
duply "$DUPLY_PROFILE" restore $TARGET_FS_ROOT/restore
But after the backup restore things failed as expected
because I use /usr/bin/true as placeholder for duply
so nothing was restored (/mnt/local/ is basically empty)
so that certain things could not work in the subsequent
'finalize' stage, in particular recreating initrd and
installing a bootloader cannot work on empty /mnt/local/.
jsmeix commented at 2024-11-21 13:10:¶
@loyeyoung
could you test how far ReaR with my changes here
works for you with real duplicity and duply?
See the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you could try out the current ReaR upstream
GitHub master code without conflicts with a
normally installed ReaR version.
To test my changes in this pull request here
(which is not yet merged into GitHub master code)
you would have checkout my branch e.g. like
git clone https://github.com/rear/rear.git
mv rear rear.github.master.jsmeix-source-DUPLY_PROFILE
cd rear.github.master.jsmeix-source-DUPLY_PROFILE
git checkout jsmeix-source-DUPLY_PROFILE
vi etc/rear/local.conf
usr/sbin/rear -D mkbackup
jsmeix commented at 2024-11-21 14:49:¶
@rear/contributors
from my point of view my changes seem to be OK
but I could not test them in real practice
because I am not a duplicity and/or duply user
so I would appreciate it if you could have a look here,
perhaps you spot problems from plain looking at the code?
jsmeix commented at 2024-11-22 08:27:¶
@rear/contributors
provided there are no objections
I would like to merge it on Monday afternoon
[Export of Github issue for rear/rear.]