detlefe added a comment.
In D8532#336584 <https://phabricator.kde.org/D8532#336584>, @fvogt wrote: > AFAICT this won't actually protect much - the open DBus socket is enough to execute arbitrary programs. > > 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. > Over that socket it receives a (read-only) file descriptor for the to be dissected file and then sends the result to baloo. 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. 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 @davidk 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. 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. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi, #frameworks, smithjd, bruns Cc: fvogt, mgallien, kde-frameworks-devel, michaelh, #baloo, detlefe, ngraham, nicolasfella, ashaposhnikov, astippich, spoorun, bruns, abrahams
