<table><tr><td style="">graesslin created this revision.<br />Restricted Application added a project: Plasma.<br />Restricted Application added a subscriber: plasma-devel.
</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/D5029" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>This change introduces a new optional dependency on libseccomp.<br />
Libseccomp allows to forbid syscalls. With that we can constrain the<br />
user defined dynamically loaded QtQuick code from the look'n'feel<br />
package and from the wallpaper package. The idea is to protect against<br />
"malicious" packages the user manually installed.</p>

<p>With the installed seccomp filter we can ensure that the QtQuick code<br />
cannot perform the following operations:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">send password into Internet through forbidding the socket syscall</li>
<li class="remarkup-list-item">use KIO to send password into Internet through forbidding fork+exec</li>
<li class="remarkup-list-item">write password into a file through forbidding opening a file in write mode or creating a new file</li>
<li class="remarkup-list-item">send password to another process through forbidding pipe/pipe2</li>
</ul>

<p>So far our QtQuick code was already constrained by disallowing network<br />
access through injecting a QNetworkAccessManager which forbids internet<br />
access. But this was easy to circumvent through e.g. KIO.</p>

<p>The seccomp filter cannot protect against a malicious process already<br />
running on the system. The obvious way to get out of this sandbox is<br />
DBus. DBus is allowed in the sandbox, thus it is possible for a malicious<br />
look'n'feel package to communicate with a running malicious application<br />
through DBus. To protect DBus we need to implement an additional apparmor<br />
profile.</p>

<p>The seccomp filter gets only installed if the seccomp dependency is<br />
available and kcheckpass is not setuid. This is ensured with a runtime<br />
check. For kscreenlocker_greet the main change is that when seccomp is<br />
enabled the delayed kcheckpass authentication method is used.</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Manual testing and a new auto test which verifies the<br />
restricted conditions.</p></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/D5029" rel="noreferrer">https://phabricator.kde.org/D5029</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>CMakeLists.txt<br />
cmake/FindSeccomp.cmake<br />
config-kscreenlocker.h.cmake<br />
greeter/CMakeLists.txt<br />
greeter/autotests/CMakeLists.txt<br />
greeter/autotests/seccomp_test.cpp<br />
greeter/greeterapp.cpp<br />
greeter/greeterapp.h<br />
greeter/main.cpp<br />
greeter/seccomp_filter.cpp<br />
greeter/seccomp_filter.h</div></div></div><br /><div><strong>To: </strong>graesslin, Plasma<br /><strong>Cc: </strong>plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol<br /></div>