[GH-ISSUE #2143] Harden against thumbnailer exploits etc.

gitea-mirror commented

2026-05-05 08:06:54 -06:00

Owner

Originally created by @curiosity-seeker on GitHub (Oct 7, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2143

Some weeks ago Tavis Ormandy published several vulnerabilities in the postscript parser of ghostscript. They have been fixed in v. 9.25.

One possible attack using those vulnerabilities is creating thumbnails (via evince in Gnome or okular in KDE). That's why thumbnailers are now sandboxed in Gnome with bubblewrap (unfortunately not in KDE AFAIK).

One interesting aspect was that Jann Horn found that AppArmor did not protect against this exploit. As a consequence some AppArmor profiles/abstractions were modified.

So as one addtional rule I would suggest to add something like

read-only @{HOME}/.local/share/thumbnailers

to disable-common.inc.

I'm not sure if this is sufficient. The general problem seems to be that a lot of the tools make use of applications with questionable security like ghostscript. A similar example was what Chris Evans published 2 years ago regarding gstreamer and tracker. Okay, there is a Firejail profile for tracker but ...

Tracker is started by systemd on most systems. Therefore it is not firejailed by default.

It's nice to know this problem does not exist for baloo.

Anyway, I wonder if the protection against these types of (potential) vulnerabilities can be improved. I'm afraid they are one of the biggest holes in Linux DEs.

Originally created by @curiosity-seeker on GitHub (Oct 7, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2143 Some weeks ago Tavis Ormandy [published](https://www.openwall.com/lists/oss-security/2018/08/21/2) several vulnerabilities in the postscript parser of ghostscript. They have been fixed in v. 9.25. One possible attack using those vulnerabilities is creating thumbnails (via evince in Gnome or okular in KDE). That's why thumbnailers are now [sandboxed](https://gitlab.gnome.org/GNOME/gnome-desktop/commit/8b1db18aa75c2684b513481088b4e289b5c8ed92) in Gnome with bubblewrap (unfortunately not in KDE AFAIK). One interesting aspect was that Jann Horn [found](https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1788929) that AppArmor did not protect against this exploit. As a consequence some AppArmor profiles/abstractions were [modified](https://gitlab.com/apparmor/apparmor/merge_requests/203/commits). So as one addtional rule I would suggest to add something like `read-only @{HOME}/.local/share/thumbnailers` to disable-common.inc. I'm not sure if this is sufficient. The general problem seems to be that a lot of the tools make use of applications with questionable security like ghostscript. A similar example was what Chris Evans [published](https://scarybeastsecurity.blogspot.com/2016/11/0day-poc-risky-design-decisions-in.html) 2 years ago regarding gstreamer and tracker. Okay, there is a Firejail profile for tracker but ... > Tracker is started by systemd on most systems. Therefore it is not firejailed by default. It's nice to know this problem does not exist for baloo. Anyway, I wonder if the protection against these types of (potential) vulnerabilities can be improved. I'm afraid they are one of the biggest holes in Linux DEs.

gitea-mirror closed this issue

2026-05-05 08:06:55 -06:00

gitea-mirror commented

2026-05-05 08:06:57 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 7, 2018):

On KDE run sandboxes with --nodbus, if possible. Then a thumbnail slave runs in the same sandbox as the application that demanded it, which is probably what you want.

Unfortunately this trick doesn't work with Dolphin, which would need it the most. Personally I've just turned the thumbnailing off in Dolphin. Also we can't enable --nodbus by default across the board, as it breaks older KDE installations.

On a side note, and unrelated to Firejail, I wonder if it would be possible to work out a tailored sandbox for KIO thumbnail slaves using Apparmor.

So as one addtional rule I would suggest to add something like read-only @{HOME}/.local/share/thumbnailers to disable-common.inc.

Absolutely. Do you want to send a pull request?

@smitsohu commented on GitHub (Oct 7, 2018): On KDE run sandboxes with `--nodbus`, if possible. Then a thumbnail slave runs in the same sandbox as the application that demanded it, which is probably what you want. Unfortunately this trick doesn't work with Dolphin, which would need it the most. Personally I've just turned the thumbnailing off in Dolphin. Also we can't enable `--nodbus` by default across the board, as it breaks older KDE installations. On a side note, and unrelated to Firejail, I wonder if it would be possible to work out a tailored sandbox for KIO thumbnail slaves using Apparmor. > So as one addtional rule I would suggest to add something like read-only @{HOME}/.local/share/thumbnailers to disable-common.inc. Absolutely. Do you want to send a pull request?

gitea-mirror commented

2026-05-05 08:06:58 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Oct 7, 2018):

On KDE run sandboxes with --nodbus, if possible. Then if the application asks for a thumbnail slave, it will run inside the same sandbox, which is probably what you want. ... Also we can't enable --nodbus by default across the board, as it breaks older KDE installations.

I have KDE Plasma 5.13.4 and KDE Frameworks 5.48.0 here on Fedora. So it should be possible to add nodbus to globals.local, shouldn't it?

Personally I've just turned the thumbnailing off in Dolphin.

Thanks - good hint!

On a side note, and unrelated to Firejail, I wonder if it would be possible to work out a tailored sandbox for KDE thumbnail slaves using Apparmor.

I think it should. Part of the problem might be that Ubuntu is using Gnome. On the other hand, openSUSE's Christian Boltz is in the Apparmor team, and openSUSE is using KDE as default DE. So perhaps there will also be changes for KDE ...

Do you want to send a pull request?

Done.

@curiosity-seeker commented on GitHub (Oct 7, 2018): > On KDE run sandboxes with --nodbus, if possible. Then if the application asks for a thumbnail slave, it will run inside the same sandbox, which is probably what you want. ... Also we can't enable --nodbus by default across the board, as it breaks older KDE installations. I have KDE Plasma 5.13.4 and KDE Frameworks 5.48.0 here on Fedora. So it should be possible to add `nodbus` to globals.local, shouldn't it? > Personally I've just turned the thumbnailing off in Dolphin. Thanks - good hint! > On a side note, and unrelated to Firejail, I wonder if it would be possible to work out a tailored sandbox for KDE thumbnail slaves using Apparmor. I think it should. Part of the problem might be that Ubuntu is using Gnome. On the other hand, openSUSE's Christian Boltz is in the Apparmor team, and openSUSE is using KDE as default DE. So perhaps there will also be changes for KDE ... > Do you want to send a pull request? Done.

gitea-mirror commented

2026-05-05 08:06:59 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Oct 7, 2018):

Just a remark regarding tracker: There is no doubt that it makes sense to sandbox it with Firejail. But as it stands, scarcely anybody will do it.

So ... shouldn't we think about offering an option during the installation routine of Firejail to create a simple systemd unit file in /etc/systemd/system ?

@curiosity-seeker commented on GitHub (Oct 7, 2018): Just a remark regarding tracker: There is no doubt that it makes sense to sandbox it with Firejail. But as it stands, scarcely anybody will do it. So ... shouldn't we think about offering an _option_ during the installation routine of Firejail to create a simple systemd unit file in /etc/systemd/system ?

gitea-mirror commented

2026-05-05 08:07:00 -06:00

Author

Owner

@Vincent43 commented on GitHub (Oct 7, 2018):

Implementing something for one app doesn't look good for me. There is systemd.exec for sandboxing systemd services.

@Vincent43 commented on GitHub (Oct 7, 2018): Implementing something for one app doesn't look good for me. There is [systemd.exec](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing) for sandboxing systemd services.

gitea-mirror commented

2026-05-05 08:07:01 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Oct 8, 2018):

I understand your reluctance. However, some counterarguments:

It's not only 1 profile that is affected. dnsmasq, unbound and dnscrypt-proxy come to my mind.
Offering profiles for them might give a false sense of security if hardly anyone uses them (because many users might not be aware that they are not automatically applied).
Yes, systemd offers sandboxing. However, most distros do not really make use of it (yet), and many users are probably not knowledgeable enough to manually enable it. While Firejail is "ideal for the regular, not-so-skilled home user". Offering to optionally install a systemd unit file which sandboxes the mentioned applications would be an easy alternative for users to make their system more secure.

I'm not saying that this should be done at all costs. I'm just trying to present some arguments as a basis for brainstorming that might lead to possible enhancements.

@curiosity-seeker commented on GitHub (Oct 8, 2018): I understand your reluctance. However, some counterarguments: 1. It's not only 1 profile that is affected. dnsmasq, unbound and dnscrypt-proxy come to my mind. 2. Offering profiles for them might give a false sense of security if hardly anyone uses them (because many users might not be aware that they are not automatically applied). 3. Yes, systemd offers sandboxing. However, most distros do not really make use of it (yet), and many users are probably not knowledgeable enough to manually enable it. While Firejail [is](https://firejail.wordpress.com/support/#why) "ideal for the regular, not-so-skilled home user". Offering to optionally install a systemd unit file which sandboxes the mentioned applications would be an easy alternative for users to make their system more secure. I'm not saying that this should be done at all costs. I'm just trying to present some arguments as a basis for brainstorming that might lead to possible enhancements.

gitea-mirror commented

2026-05-05 08:07:02 -06:00

Author

Owner

@Vincent43 commented on GitHub (Oct 8, 2018):

Offering profiles for them might give a false sense of security if hardly anyone uses them (because many users might not be aware that they are not automatically applied).

Offering profiles doesn't add any security on its own, it only make firejail easier to use than similar apps which don't come with that many profiles.

Yes, systemd offers sandboxing. However, most distros do not really make use of it (yet), and many users are probably not knowledgeable enough to manually enable it.

So, installing units with full systemd.exec sandbox would be even better thing to do but out of scope for firejail. Manipulating systemd units is IMO too much interference in host system.

While Firejail is "ideal for the regular, not-so-skilled home user". Offering to optionally install a systemd unit file which sandboxes the mentioned applications would be an easy alternative for users to make their system more secure.

In text you linked it's stated: just prefix your application with “firejail” and run it. There isn't just install firejail and be secure promise. Also there is no such thing like "optional" install. It may be an option to firecfg but how those not-so-skilled home users will find it then? How you will resolve conflicts with systemd.exec, apparmor, selinux, etc?

@Vincent43 commented on GitHub (Oct 8, 2018): > Offering profiles for them might give a false sense of security if hardly anyone uses them (because many users might not be aware that they are not automatically applied). Offering profiles doesn't add any security on its own, it only make firejail easier to use than similar apps which don't come with that many profiles. > Yes, systemd offers sandboxing. However, most distros do not really make use of it (yet), and many users are probably not knowledgeable enough to manually enable it. So, installing units with full systemd.exec sandbox would be even better thing to do but out of scope for firejail. Manipulating systemd units is IMO too much interference in host system. > While Firejail is "ideal for the regular, not-so-skilled home user". Offering to optionally install a systemd unit file which sandboxes the mentioned applications would be an easy alternative for users to make their system more secure. In text you linked it's stated: _just prefix your application with “firejail” and run it_. There isn't _just install firejail and be secure_ promise. Also there is no such thing like "optional" install. It may be an option to `firecfg` but how those _not-so-skilled home users_ will find it then? How you will resolve conflicts with systemd.exec, apparmor, selinux, etc?

gitea-mirror commented

2026-05-05 08:07:03 -06:00

Author

Owner

@Vincent43 commented on GitHub (Oct 10, 2018):

Adding to the above:

We couldn't just replace systemd units as those may differ across distros. Overriding ExecStart has the same concern as there may be different arguments passed.

The risk to create random breakages is too big for that route..

@Vincent43 commented on GitHub (Oct 10, 2018): Adding to the above: We couldn't just replace systemd units as those may differ across distros. Overriding `ExecStart` has the same concern as there may be different arguments passed. The risk to create random breakages is too big for that route..

gitea-mirror commented

2026-05-05 08:07:03 -06:00

Author

Owner

@Vincent43 commented on GitHub (Oct 16, 2018):

Closing as read-only @{HOME}/.local/share/thumbnailers is done and there is nothing else to do.

@Vincent43 commented on GitHub (Oct 16, 2018): Closing as `read-only @{HOME}/.local/share/thumbnailers` is done and there is nothing else to do.

gitea-mirror referenced this issue

2026-05-05 10:12:11 -06:00

[PR #1544] [MERGED] localhost mail fix for mutt #4013

Rows
Columns

[GH-ISSUE #2143] Harden against thumbnailer exploits etc. #1454