Use Seccomp for implementing a sandbox for baloo_file_extractor
This change introduces a new optional dependency on libseccomp.
Libseccomp allows to forbid syscalls. With that we can constrain the
extractor process.
This is important because the extractors are parsing multimedia files with
libraries like FFmpeg. These libraries have sometimes bugs in their parsers,
allowing code execution. This can result in remote code execution
vulnerabilities, because webbrowsers like Google Chrome are downloading files
from websites automatically, and place them in your download folder. Then,
baloo will pick them up and parse them, which allows the attacker to trigger
bugs in e.g. FFmpeg. Such an attack has been demonstrated for Gnome Tracker[1].
If the attacker is able to execute code on your system, he/she might try to
mess with your home directory, e.g. encrypt it ("ransomware", very widespread
on Windows), or send your files to a webserver. This change tries to defeat
suchs attacks, by forbidding all syscall which could mess up your
files or send them to a server by using Seccomp. This is done using a blacklist
of systemcalls. Using a whitelist would be possible, but the we don't know what
syscalls third-party extractors might use, so I tried to make the impact on
them as small as possible. Extractors opening files in read-write mode will
fail and need to be fixed (I don't think they should do this). If a user uses an
extractor which gets restricted by Seccomp, he/she can set the
BALOO_DISABLE_SECCOMP environment variable to disable the sandboxing.
One can debug such issues by running "dmesg | grep baloo_file_extractor", as
Seccomp violations show up in dmesg (you may need to enable this with auditctl).
This would also be possible using AppArmor or SELinux (maybe even better),
but these aren't available on all distributions, while Seccomp is AFAIK
available on most distributions. Of course one could combine them, and use
e.g. Seccomp and AppArmor.
Unfortunately kidletime opens a X11 socket, so an attacker can control every
X11 application. Wayland fixes this.
The Seccomp filter gets only installed if the Seccomp dependency is
available.
Credits go to Martin Flöser. He did something similar for kscreenlocker,
and my work is mostly an adaption of his work.
This is work in process: I want to get some feedback on the general idea and on
these TODO items:
- Maybe use a whitelist instead of a blacklist?
- FindSeccomp.cmake is now in ecm, this one should be removed as soon as we can depend on it.
- Check whether CI has seccomp installed.
FEATURE: 408570