Re: gnome-sdk update and TODOs

[Tanu Kaskinen <tanu kaskinen linux intel com>]

On Tue, 2014-12-16 at 13:40 +0100, Alexander Larsson wrote:
> On tis, 2014-12-16 at 10:15 +0200, Tanu Kaskinen wrote:
> > On Tue, 2014-12-16 at 09:48 +0530, Arun Raghavan wrote:
> > > On 15 Dec 2014 13:29, "Alexander Larsson" <alexl redhat com> wrote:
> > > > On fre, 2014-12-12 at 17:42 +0100, Bastien Nocera wrote:
> > > > > On Fri, 2014-12-12 at 17:08 +0100, Alexander Larsson wrote:
> > > > > > On fre, 2014-11-28 at 16:07 +0100, Alexander Larsson wrote:
> > > > > > > * Audio
> > > > > > >
> > > > > > >  There is no audio support atm. Neither alsa libs, not device nodes.
> > > > > > >  I think the best approach is to use pulseaudio, but this needs
> > > > > > >  careful consideration in terms of ABI/IPC compat, performance,
> > > > > > >  latency, etc.
> > > > > >
> > > > > > Today I looked at audio via pulseaudio. This is kind of tricky, it seems
> > > > > > to me like the pulseaudio protocol follows the X11 style permissions
> > > > > > method. I.e. if you're able to authenticate to the daemon you have full
> > > > > > privs, including loading modules into the daemon.
> > > > > >
> > > > > > Furthermore, the "normal" mode of using shared memory to send audio
> > > > > > relies on a single global /dev/shm, which breaks with any kind of
> > > > > > containerization and allows any client to read any other clients data.
> > > > > >
> > > > > > I don't see why theoretically pulseaudio couldn't allow shared memory
> > > > > > buffers in a contained mode, via e.g. fd passing of the shared memory
> > > > > > instead of a shared namespace. However, anything like this involves
> > > > > > upstream changes to the protocol. For now i'm disabling shared memory
> > > > > > in the app, which is not ideal but at least allows apps to play sounds.
> >
> > In my experience the performance benefit of using shared memory in
> > PulseAudio is small, so I wouldn't be too worried about disabling it.
> >
> > > > > Lennart did mention that PulseAudio could make use of kdbus for passing
> > > > > buffers around, and I guess that Wim's "PulseVideo" (for the lack of a
> > > > > better name) could also make use of it.
> > > > >
> > > > > Finer permissions are necessary in any case. You can probably allow any
> > > > > app to play sound, but you might not want to allow microphone access to
> > > > > most applications.
> > > >
> > > > Yeah, this level of permissions will need some drastic changes to the
> > > > pulseaudio client handling. Perhaps it is possible to do while keeping
> > > > the protocol, not sure about that. But in general, a kdbus version would
> > > > be pretty nice as this would remove the issues around having to
> > > > share /dev/shm with the host.
> > >
> > > Yes, kdbus is something that could be useful to plug this leak (though
> > > we'd also need to make sure we don't add much overhead). In general,
> > > securing the protocol is something we'd like to have, but is a huge
> > > can of worms right now -- securing the protocol post-facto will be
> > > hard to do right.
> >
> > As I see it, the system for fine-grained permissions should be
> > protocol-agnostic. Implementing that system is a lot of work. Adapting
> > the current native protocol implementation to that is probably a smaller
> > task - all commands already can fail for whatever reason, so it
> > shouldn't be a big deal to add cases where they fail for "permission
> > denied" reasons.
>
> Just denying an operation is not very hard. True. But in the current
> protocol, how would you know what permissons profile to apply? We can't
> depend on the uid as it will generally be the same. We should probably
> base it on the cgroup of the remote peer, but there is currently no
> race-free way to get that (only way is
> getpeercred->pid->/proc/$pid/cgroup which is racy). kdbus does have
> robust ways to get this (including other peer properties like selinux
> context).

Ok, so kdbus would be beneficial, perhaps even required, as an
authentication mechanism for sandboxed apps. So there are three layers
to consider: 1) connection authentication, 2) the communication protocol
and 3) the access control enforcement. kdbus code in PulseAudio could
choose to implement only the authentication (after successful
authentication, perhaps a pipe fd could be passed via kdbus and the old
protocol would then take over, using the pipe as a transport), or the
kdbus code could also implement a full D-Bus API so the old protocol
wouldn't be involved at all.

The access control enforcement part doesn't have to be specific to the
kdbus protocol, but I can imagine that whoever implements the kdbus
protocol might want to implement the access control enforcement inside
the kdbus code to avoid doing big changes to the PulseAudio core code.

-- 
Tanu