throw Baloo in jail

File indexing tools encounter all different types of files, both of trusted and untrusted origin, and last November it was demonstrated by Chris Evans how this can potentially be exploited*. In order to provide a means for mitigation, I have written a Firejail profile** for Baloo recently

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. A whitelist, even if it is broad, would be desirable to reduce the attack surface of the kernel, and is also the way it was done for Gnome Tracker. But the concerns about maintenance remain, someone should test it regularly. Are there ways this can be automated?

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. I'm just an interested user and cannot comment on the question of external plugins. But before this enters a deep sleep, I wonder if at least the //current// patch should find its way into the extractors or into kfilemetadata. A whitelist is the real thing, and

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. In 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

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. Dropping one more comment, in case someone wants to give it a try: Apparmor profile transitions don't work if a seccomp filter has been installed before. This makes it probably rather difficult to integrate DrKonqi into an Apparmor policy. REPOSITORY R293 Baloo