throw Baloo in jail

Detlef Eppers eppers at posteo.de
Fri May 5 16:37:55 UTC 2017


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 (Firejail is a SUID sandboxing tool, modeled after the Chromium 
sandbox).

However, almost all the stuff I do now with Firejail (seccomp filter, 
dropping capabilities, namespaces, file system restrictions) could 
equally be done through a systemd unit file, providing better security 
for all Plasma users. So my question number one is if for Baloo, 
switching to a systemd user unit could be considered a viable option 
(versus the current autostart mechanism).

Question number two: I would like to restrict Baloo's access to the file 
system through Firejail. But if I bind-mount the home directory 
write-protected and only ~/.local/share/baloo as writable, baloo_file 
will fail to launch, printing:

Failed to create database, removing corrupted database.
Failed to create database after deleting corrupted one.

If the whole ~/.local/share is writable however, everything works as 
expected.

Similarly, baloo_file won't write to its configuration file 
~/.config/baloofilerc if it is remounted writable. Only if the whole 
~/.config folder is writable everything works as expected. To me this 
looks like Baloo wants to create write-locks, and the question is if one 
could conceive an alternative mechanism. This would not only help to 
write tighter Firejail profiles, but also in restricting baloo_file as 
much as possible through a systemd execution environment.

Thank you for your thoughts and any insight.

Cheers,
Detlef

*Link to Chris Evans blog post: 
https://scarybeastsecurity.blogspot.de/2016/11/0day-poc-risky-design-decisions-in.html
**Link to the Firejail profile in question: 
https://github.com/netblue30/firejail/blob/master/etc/baloo_file.profile
Back then the profile used to work with last lines uncommented, now it 
doesn't any more.



More information about the Kde-frameworks-devel mailing list