#2779 Issue closed: DISA STIG secured Red Hat system: libraries failing to copy during mkrescue ('fapolicyd' hinders it)

Labels: support / question, fixed / solved / done, external tool, not ReaR / invalid

rtinsley87 opened issue at 2022-03-25 19:18:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
    2.6

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
    Red Hat 8.5

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

export TMPDIR=/mnt/backup/Admin/tmp
OUTPUT=ISO
OUT_URL=file:///mnt/backup
COPY_AS_IS+=(/usr/lib*)

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
    PC

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86 compatible

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI & GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local SSD

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

  • Description of the issue (ideally so that others can reproduce it):

This system is being setup for secure use so it was imaged
configured with the DISA stig for Red hat 8.5 with GUI.
When I run a the command "sudo rear -v mkrescue" it fails with a error warning

BUG in /usr/share/rear/build/default/990_verify_rootfs.sh line 48:
'\''ReaR recovery system in '\''/mnt/backup/Admin/tmp/rear.ssBwqpOHnTJkjO0/rootfs'\'' is broken: '\''bash -c true'\'' failed'\''

and it also shows this during recovery system test

/bin/bash: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: Operation not permitted

When I checked the rootfs folder under usr/lib libtinfo.so.6 is missing from the folder.
I tried including the configuration line LIBS=(libtinfo.so.6) and it will give a line
during the verbose run that says libtinfo.so.6 failed to copy.

  • Workaround, if any:
    tested on VM without controls implemented during imaging
    and just required grub2 modules to be installed

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files): rear-Thuja.log

rtinsley87 commented at 2022-03-29 17:24:

I was able to resolve this issue by adding "EXCLUDE_MOUNTPOINTS=(/dev/sdb)" to my local.conf. This was the secondary drive for the backup itself.

So the local.conf looks like this:

export TMPDIR="//mnt/backup/Admin/tmp"
BACKUP=NETFS
NETFS_KEEP_OLD_BACKUP_COPY=y
EXCLUDE_MOUNTPOINTS=(/dev/sdb)
OUTPUT=ISO
OUTPUT_URL=file:///mnt/backup/Admin/Rescue
BACKUP_PROG=rsync
BACKUP_URL=file:///mnt/backup/Admin/Backup
FULLBACKUP=THU

rtinsley87 commented at 2022-03-29 22:58:

Further investigating revealed that these settings didn't fix the issue but removing and re-installing fapolicyd application fixes it. This app controls app and file whitelist and is required under the stig

jsmeix commented at 2022-03-30 06:22:

@rtinsley87
thank you for your feedback what the actual root cause is.
Such feedback helps us at ReaR upstream a lot because now we know
there is no hidden bug in ReaR and - at least I - learned about
yet another security thingy that hinders what even 'root' can do
besides the well known suspects "AppArmor" and "SELinux"
(because "rear mkresue" runs as 'root' one assumes it has unlimited permissions).

You wrote "removing and re-installing fapolicyd":
According to
https://github.com/linux-application-whitelisting/fapolicyd
fapolicyd is a "File Access Policy Daemon" so I would assume
it should be sufficient to only stop this daemon before "rear mkrescue"
and re-start it afterwards.
But this removes fapolicyd protection while "rear mkrescue" is running
so I think a better solution would be to configure fapolicyd appropriately
so that "rear mkrescue" can work.
But I know nothing about fapolicyd whether or not it can be configured
this way with reasonable effort.

rtinsley87 commented at 2022-03-30 16:00:

@jsmeix
Thank you for following up! My supervisor and I are Windows users mainly so I didn't think about fapolicyd being a daemon or service in Windows that I could stop instead. I believe what may have happened is that the daemon generates a default whitelist when it is initially installed which is during the OS installation and when I removed and reinstalled it generated a new default list that included everything currently on the system or maybe not to that extent. The point is that, the rescue ISO creation would work after the daemon was reinstalled and active as well as if I uninstalled it then ran rescue and then re-installed.

I agree that we should configure it correctly if we want to leave it installed. Thank you for providing the github link for fapolicyd so that we can understand it better.

[Export of Github issue for rear/rear.]