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.
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 ?
@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)
(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
(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.
(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)?
(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.
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.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/tumbler/-/issues/17. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev