Re: gnome-sdk update and TODOs

[Rob Taylor <rob taylor codethink co uk>]

On 15/12/14 07:56, Alexander Larsson wrote:
> On fre, 2014-12-12 at 18:39 +0000, Rob Taylor wrote:
> > On 11/12/14 10:32, Alexander Larsson wrote:
> > > On fre, 2014-11-28 at 16:07 +0100, Alexander Larsson wrote:
> > > > * OpenGL
> > > >
> > > >    There is no opengl yet in the base image, and making this work will
> > > >    be a lot of work, since mesa uses udev and dri devices, relies on
> > > >    particular kernel/Xorg drivers, etc. It also needs to be replacable
> > > >    easily as the way you install a different gl driver is to replace the
> > > >    entire GL library.
> > > >
> > > >    Mesa is also pretty unsafe in terms of sandboxing for anything before
> > > >    DRI3, as DRI2 buffer handles are global and guessable. Dunno about
> > > >    e.g. nvidia.
> > > >
> > > >    This will require a lot of ad-hoc work, and probably some setup to
> > > >    replace part of a runtime with another sub-runtime.
> > >
> > > I've been looking a bit at OpenGL support. The way the mesa (DRI)
> > > drivers work is that there are device nodes in /dev/dri, which have
> > > rights such that the user can open them (typically by being in the video
> > > group, or due to the system setting acls on them for the currently
> > > logged in user). These nodes are "safe" to expose as they don't give any
> > > raised privileges on open. Operations that are unsafe generally have to
> > > be authenticated in some way first.
> > >
> > > However, there are still some security issues here. The DRI2 driver APIs
> > > use global guessable 32bit handles (from gem_flink) for buffers, so
> > > anyone can read anyones buffers. This is solved with DRI3 which uses fd
> > > passing instead of int handles.
> > >
> > > Obviously, this is kind of uninteresting atm as I'm currently targeting
> > > X11 apps which is completely unsecure in this sense anyway. However,
> > > when we later switch to wayland and sandboxing we need to ship *only*
> > > DRI3 drivers, and assume the host supports these.
> > >
> > > To make the drivers work the runtime bind mounts the host /dev/dri into
> > > the container. This will work for the dri drivers, but I guess we needs
> > > to also take a look at e.g. the nvidia drivers and the amd drivers to
> > > see what devices they use, how safe they are to expose, and them mount
> > > them in too.
> >
> > I had some discussion with Daniel Stone around this a month back or so.
> >
> > The vague plan is to add to the wl_drm protocol to pass an FD for the
> > rendernode, rather than the DRI card. This should work well for all
> > cards with rendernode support, which should be most pretty soon, iirc.
> > It also avoids the gem_flink security hole.
> >
> > I'm hoping to get round to implementing this over the holiday period
> > (after nspawn kdbus endpoint support in systemd)
>
> There are two issues here. First of all, we don't want the apps buffers
> from the app to be accessible by others, this is solved by not naming
> them via flink and instead passing fds).
>
> The second issue is that a sandboxed app should not be able to access
> named buffers at all, if something accidentally uses these on the host.
> Is this disallowed by render-nodes?

Yep, render nodes use dmabuf for buffer handles, handling both these issues.

You can find a good overview at: 
https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/

Another benefit to passing an fd rather than a string for which card to 
open will be that the container can have a device cgroup that hides all 
hardware devices.

HTH
Rob