sandbox thumbnailers

Submitted by Yves-Alexis Perez

Assigned to Ali Abdallah @ali

Link to original bug (#14626)

Description

I wrongly though I had already opened a bug against tumbler about this, but I can't find it so I guess I'm wrong.

It would be nice to execute the thumbnailers through a sandbox, because thumbnailers by nature parse complex formats from file with sometime spurious origin. There have been multiple vulnerabilities in video, image or PDF parsers which could lead to code execution. Latest one is a series in ghostscript (see thread at http://openwall.com/lists/oss-security/2018/08/21/2 for example).

While tumbler or its dependencies might not be vulnerable to specific vulnerabilities, it's quite possible that it will be to some other in the future. Thumbnailing is enabled even for files on removable storage or downloaded from the internet. Hardening the thumbnailers and tumblerd itself so it runs sandboxed would be nice. On Linux seccomp can help, shipping some AppArmor/SELinux rules might help too, and maybe projects like bublewrap would be interesting as well.

Alexander Schwinn @alexxcons said:

You think we as well should consider a quick-fix + release for the 4.12 branch, like disable thumbnails for PS, EPS, PDF and XPS, until the ghostscript vulnerabilities have been fixed ?

Ali Abdallah @ali said:

@Yves-Alexis

I had done some analysis on implementing the thumbnailers through a sandbox. I should even have some code somewhere. tumbler needs to be modified heavily, and it would need to be SUID to setup the sandbox when it starts.

1. On Linux seccomp+namespaces can be used
2. On FreeBSD capsicum+jail
3. On others? dunno

I'm planning this feature for 0.4.0, will keep you informed.

@alexxcons

No, I don't think it is wise to do a release waiting for the ghostscript vulnerabilities to be fixed, and another one after the fix (you can iterate this cycle)

Yves-Alexis Perez said:

(In reply to Ali from comment 2)

@Yves-Alexis

I had done some analysis on implementing the thumbnailers through a sandbox. I should even have some code somewhere. tumbler needs to be modified heavily, and it would need to be SUID to setup the sandbox when it starts.

To be honest, writing a sandbox looks hard enough to me, and there are a lot of things to pay attention to in order to have a relevant security model. I'm not sure writing it from scratch is really a good idea. Would it make sense to rely on external sandboxes/libraries like bubblewrap or firejail?

1. On Linux seccomp+namespaces can be used

LSM like AppArmor/SELinux can help here too

Ali Abdallah @ali said:

(In reply to Yves-Alexis Perez from comment 3)

(In reply to Ali from comment 2)

@Yves-Alexis

I had done some analysis on implementing the thumbnailers through a sandbox. I should even have some code somewhere. tumbler needs to be modified heavily, and it would need to be SUID to setup the sandbox when it starts.

To be honest, writing a sandbox looks hard enough to me, and there are a lot of things to pay attention to in order to have a relevant security model.

You don't really need implement a complex sandbox, it is enough to give read only access on the image for which tumbler should generate a thumbnail, and write access to the ~/.cache/thumbnails/{flavor}/xxxxxxxxxxxxxxxxxxxxxxxxxx.png

I'm not sure writing it from scratch is really a good idea. Would it make sense to rely on external sandboxes/libraries like bubblewrap or firejail?

One can already run tumbler under firejail, a good firejail profile for tumblerd should forbid access to sensitive data such as .ssh, .gpg, etc... and gives write access to ~/.cache/thumbnails, but it is up to distros/users whether to choose to run tumbler under in that way.

1. On Linux seccomp+namespaces can be used LSM like AppArmor/SELinux can help here too

I would only rely on common kernel API, available among all Linux distros.

Anna Arad said:

(In reply to Ali from comment 2)

3. On others? dunno

OpenBSD - Pledge and Unveil (Unveil seems to be only on OpenBSD-current at the moment)

(In reply to Ali from comment 4)

I would only rely on common kernel API, available among all Linux distros.

What about Non-Linux systems (Like the BSDs)?

Ali Abdallah @ali said:

(In reply to Anna Arad from comment 5)

(In reply to Ali from comment 2)

3. On others? dunno

OpenBSD - Pledge and Unveil (Unveil seems to be only on OpenBSD-current at the moment)

I was having a look at Pledge.

(In reply to Ali from comment 4)

I would only rely on common kernel API, available among all Linux distros.

What about Non-Linux systems (Like the BSDs)?

Well, I meant that on Linux I will use common kernel API. On BSDs I will use whatever available sandboxing framework, like capsicum on FreeBSD.

Ali Abdallah @ali said:

Here are my conclusions, after having done some experiments on various sandboxing frameworks.

1. tumblerd will run always as normal user, and will only use userspace sandboxing framework. No SUID thing to setup complex sandboxing.
2. seccomp filters are what will be used on Linux to restrict access to system calls.
3. capsicum on FreeBSD
4. pledge on OpenBSD
5. disabled when no supported framework is available. ...

All these frameworks are very easy to use and don't require root access. Basically when tumblerd receives thumbnailing request, it loads it from cache if found, otherwise, it setup an fd with read only access on the required file, fd with write access for the output thumbnail, vfork itself, setup system calls restriction (on the child), run the thumbnailer.

The only down thing is that the desktop thumbnailer (the plugin that loads .thumbnailers) will be obsolete, as it is impossible to control what the executed script will be doing, but probably this is point of sandboxing tumbler anyway.

Another option is to add Sandbox bit to the configuration file for each plugin, ex.

[OdfThumbnailer] Disabled=false Priority=1 Locations= MaxFileSize=0 Sandbox=true

[DesktopThumbnailer] Disabled=true Priority=1 Locations= MaxFileSize= Sandbox=false

I started working on this feature for the 0.4.x release.

unassigned @ali

added 2. Feature label

mentioned in issue #69 (closed)

We could use Flatpak to achieve this easily. This would obviously not be native, but still officially supported, as a kind of alternative sandboxed version.

I've already packaged Tumbler in flatpak as a dependency of Ristretto, I could do it (not necessarily right away though).

@snizio what do you think?

marked this issue as related to #69 (closed)

@Tamaranch, I'm not sure how well would that work in combination with thumbler or Xfce installed on system (the one from Flatpak should take priority for this to be effective). Personally, I don't use Flatpak so it's hard for me to say much about it. If it's possible then it would be a nice possibility. For what it's worth, I have read somewhere that Flatpak is best for applications not services.

From among other options, it is possible to create a systemd service, for thumblerd to be run as user, and use the sandbox capabilities. It should be easy but is not portable.

I'm not sure how well would that work in combination with thumbler or Xfce installed on system (the one from Flatpak should take priority for this to be effective)

I think it should be the default, to be tested.

For what it's worth, I have read somewhere that Flatpak is best for applications not services.

I don't know, it's possible, but in any case running a service via flatpak is possible (I actually already tested for Tumbler when I packaged Ristretto, i.e. not only as a private thumbnailer only for Ristretto).

it is possible to create a systemd service, for thumblerd to be run as user, and use the sandbox capabilities

Tumbler is already running as a systemd service since 1c2102e5 normally (if systemd is installed), i.e. since Tumbler 4.17.0, so that should make things easier (including for prioritization too, resource allocation, etc.).