Re: gnome-sdk update and TODOs

[Alexander Larsson <alexl redhat com>]

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).