D8532: [WIP] Restrict file extractor with Seccomp

[David Kahles]

davidk created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  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:
  
  - If this breaks frameworks compatibility promises, we should add metadata to the extractor plugins, and only enable the filter if all extractors support it. Then we could use a whitelist of syscalls.
  - FindSeccomp.cmake is now duplicated (copied from kscreenlocker). Should we move it into ECM? Also, I think we would need to relisence it.

TEST PLAN
  - ran a full reindex with wiped config and database, including the kfilemetadata samplefiles
    - Got no Seccomp violations (checked with strace and dmesg)
    - Writing files from the extractor fails with EPERM
    - Seccomp Test is green
  
  [1] https://scarybeastsecurity.blogspot.de/2016/11/0day-poc-risky-design-decisions-in.html?m=1

REPOSITORY
  R293 Baloo

BRANCH
  seccomp

REVISION DETAIL
  https://phabricator.kde.org/D8532

AFFECTED FILES
  CMakeLists.txt
  cmake/FindSeccomp.cmake
  config.h.cmake
  src/file/extractor/CMakeLists.txt
  src/file/extractor/app.cpp
  src/file/extractor/app.h
  src/file/extractor/autotests/CMakeLists.txt
  src/file/extractor/autotests/seccomp_test.cpp
  src/file/extractor/main.cpp
  src/file/extractor/seccomp_filter.cpp
  src/file/extractor/seccomp_filter.h

To: davidk
Cc: #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20171028/92c3936c/attachment-0001.html>