[Spice-devel] Spice, GStreamer and seccomp issue

[Frediano Ziglio]

> 
> Hello,
> 
> I share for information the problem and solution I encountered why
> trying to run spice-server gstreamer encoding on Fedora30:
> 
> > warning: GStreamer: External plugin loader failed. This most likely means
> > that the plugin loader helper binary was not found or could not be run.
> > You might need to set the GST_PLUGIN_SCANNER environment variable if your
> > setup is unusual. This should normally not be required though.
> 
> this was due to seccomp syscall filtering, as my (virsh) VM was
> running with this option:
> 
> > -sandbox
> > on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
> 
> I don't know what is the clean way to solve it, but patching qemu to
> force "-sandbox off" gets rid of the codec issue
> 
> 
> regards,
> 
> Kevin

So, Fedora 30 added some security feature to disable loading plugins from
Qemu executable.
The reason is that potentially Qemu could be exploited using the VM code
which is by definition insecure and so different security checks are enabled.
Even if you disable the new sand boxing feature GStreamer won't work as
execmem (that is allowing to craft code dynamically), used by liborc, a base
library of many GStreamer plugins, is disabled too.

As many of these feature are per-process the "solution" seems to do these
stuff (encoding in this case) in another process.
Separating just the encoding instead of all SPICE seems to me much easier
(some features are strongly dependent on sharing pointers and buffers).
I see 2 possible choices:
- encoding process as a child of SPICE server (that is Qemu process);
- encoding process as not a child of SPICE server. This requires some
  sort of daemon launched before any Qemu process.
Both have security concerns; Qemu will be able to access some features
which are, for security reasons, disabled. In the first case the child
process will have to elevate it's privileges making it possible to use
the required features (execmem requires to change SELinux context which
requires an execve call, fork is not enough). In the second case you
allows any process to ask for these services.

Frediano