<table><tr><td style="">detlefe added a comment.
</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">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D8532#336584" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D8532#336584</a>, <a href="https://phabricator.kde.org/p/fvogt/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@fvogt</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>AFAICT this won't actually protect much - the open DBus socket is enough to execute arbitrary programs.</p>

<p>The best design would be (IMO, not sure how well the current architecture fits) to have a fully sandboxed executable which can only communicate with baloo over a single socket.<br />
 Over that socket it receives a (read-only) file descriptor for the to be dissected file and then sends the result to baloo.</p></div>
</blockquote>

<p>I love the proposal(!), but just in case a full sandbox is wanted here and large changes to (unmaintained) baloo are out of scope, maybe a combination of Apparmor and seccomp could offer a way out. Note that this was also proposed by Martin Flöser for the original kscreenlocker seccomp sandbox, but as far as I know never implemented.</p>

<p>Apparmor has the advantage that access to DBus can be controlled in a very fine grained way, that writing a profile should be relatively straightforward and that users can debug (or adapt) the profile easily. The main disadvantage is that it is not available everywhere, as pointed out already by <a href="https://phabricator.kde.org/p/davidk/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@davidk</a> in the summary. Regarding this latter point, however, it is maybe worth pointing out that also a proper sandbox is not necessarily available everywhere. The question here is how would you do it? You need root to set it up, and there are in the moment two ways to get there: Unprivileged user namespaces, which are not available in all distributions (Arch, Debian, ...), or SUID root, which is risky and hard to get it right. Bubblewrap or something like that would introduce an additional dependency.</p>

<p>One advantage of seccomp is that it works basically everywhere. Also I tend to disagree on the suggestion that it is useless. Whitelists can have properties of a real sandbox, but usually the role of seccomp is to reduce attack surface... this is why it exists, what seccomp was designed for, and why IMHO it makes a lot of sense for Baloo even if there is not a perfect solution/if Apparmor is unavailable.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R293 Baloo</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8532">https://phabricator.kde.org/D8532</a></div></div><br /><div><strong>To: </strong>davidk, apol, ossi, Frameworks, smithjd, bruns<br /><strong>Cc: </strong>fvogt, mgallien, kde-frameworks-devel, michaelh, Baloo, detlefe, ngraham, nicolasfella, ashaposhnikov, astippich, spoorun, bruns, abrahams<br /></div>