throw Baloo in jail

[Martin Flöser]

Am 2017-05-05 18:37, schrieb Detlef Eppers:
> 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).

Only if you want to fight an uphill battle. I would not suggest to go 
for systemd unit files. There are distributions who threatened to drop 
all of KDE if there is only one component which depends on systemd.

Instead I would suggest to go for using seccomp directly in baloo 
similar to what I did in kscreenlocker_greet for Plasma 5.10.

> 
> 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.

 From my testing with seccomp on kscreenlocker_greet it is just not 
possible to start an application with privs restricted. Instead open the 
database and then install the seccomp filter. All we need is to know 
that once it starts to parse a file it's no longer able to write to any 
file.

> 
> 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.

Right, things are using lock files. I doubt you can change that as 
that's probably directly in KConfig. I also stumbled over that when 
doing the seccomp filtering. It was one of the problems which pushed me 
towards only installing the filter once everything is setup but before 
untrusted code gets executed.

In case you are interested:
https://cgit.kde.org/kscreenlocker.git/commit/?id=5e3c7b337c9525f6b427c06f1814938b0a161db8

is the commit which introduced seccomp filtering in kscreenlocker.

Oh and thanks for having a look at it! This is in my opinion really low 
hanging fruit to get baloo more secure.

Cheers
Martin