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