<table><tr><td style="">davidk created this revision.<br />Restricted Application added a project: Frameworks.<br />Restricted Application added a subscriber: Frameworks.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8532" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Use Seccomp for implementing a sandbox for baloo_file_extractor</p>

<p>This change introduces a new optional dependency on libseccomp.<br />
Libseccomp allows to forbid syscalls. With that we can constrain the<br />
extractor process.</p>

<p>This is important because the extractors are parsing multimedia files with<br />
libraries like FFmpeg. These libraries have sometimes bugs in their parsers,<br />
allowing code execution. This can result in remote code execution<br />
vulnerabilities, because webbrowsers like Google Chrome are downloading files<br />
from websites automatically, and place them in your download folder. Then,<br />
baloo will pick them up and parse them, which allows the attacker to trigger<br />
bugs in e.g. FFmpeg. Such an attack has been demonstrated for Gnome Tracker[1].</p>

<p>If the attacker is able to execute code on your system, he/she might try to<br />
mess with your home directory, e.g. encrypt it ("ransomware", very widespread<br />
on Windows), or send your files to a webserver. This change tries to defeat<br />
suchs attacks, by forbidding all syscall which could mess up your<br />
files or send them to a server by using Seccomp. This is done using a blacklist<br />
of systemcalls. Using a whitelist would be possible, but the we don't know what<br />
syscalls third-party extractors might use, so I tried to make the impact on<br />
them as small as possible. Extractors opening files in read-write mode will<br />
fail and need to be fixed (I don't think they should do this). If a user uses an<br />
extractor which gets restricted by Seccomp, he/she can set the<br />
BALOO_DISABLE_SECCOMP environment variable to disable the sandboxing.<br />
One can debug such issues by running "dmesg | grep baloo_file_extractor", as<br />
Seccomp violations show up in dmesg (you may need to enable this with auditctl).</p>

<p>This would also be possible using AppArmor or SELinux (maybe even better),<br />
but these aren't available on all distributions, while Seccomp is AFAIK<br />
available on most distributions. Of course one could combine them, and use<br />
e.g. Seccomp and AppArmor.</p>

<p>Unfortunately kidletime opens a X11 socket, so an attacker can control every<br />
X11 application. Wayland fixes this.</p>

<p>The Seccomp filter gets only installed if the Seccomp dependency is<br />
available.<br />
Credits go to Martin Flöser. He did something similar for kscreenlocker,<br />
and my work is mostly an adaption of his work.</p>

<p>This is work in process: I want to get some feedback on the general idea and on<br />
these TODO items:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">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.</li>
<li class="remarkup-list-item">FindSeccomp.cmake is now duplicated (copied from kscreenlocker). Should we move it into ECM? Also, I think we would need to relisence it.</li>
</ul></div></div><br /><div><strong>TEST PLAN</strong><div><ul class="remarkup-list">
<li class="remarkup-list-item">ran a full reindex with wiped config and database, including the kfilemetadata samplefiles<ul class="remarkup-list">
<li class="remarkup-list-item">Got no Seccomp violations (checked with strace and dmesg)</li>
<li class="remarkup-list-item">Writing files from the extractor fails with EPERM</li>
<li class="remarkup-list-item">Seccomp Test is green</li>
</ul></li>
</ul>

<p>[1] <a href="https://scarybeastsecurity.blogspot.de/2016/11/0day-poc-risky-design-decisions-in.html?m=1" class="remarkup-link" target="_blank" rel="noreferrer">https://scarybeastsecurity.blogspot.de/2016/11/0day-poc-risky-design-decisions-in.html?m=1</a></p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R293 Baloo</div></div></div><br /><div><strong>BRANCH</strong><div><div>seccomp</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8532" rel="noreferrer">https://phabricator.kde.org/D8532</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>CMakeLists.txt<br />
cmake/FindSeccomp.cmake<br />
config.h.cmake<br />
src/file/extractor/CMakeLists.txt<br />
src/file/extractor/app.cpp<br />
src/file/extractor/app.h<br />
src/file/extractor/autotests/CMakeLists.txt<br />
src/file/extractor/autotests/seccomp_test.cpp<br />
src/file/extractor/main.cpp<br />
src/file/extractor/seccomp_filter.cpp<br />
src/file/extractor/seccomp_filter.h</div></div></div><br /><div><strong>To: </strong>davidk<br /><strong>Cc: </strong>Frameworks<br /></div>