Dne 31.1.2019 v 01:45 Phil Burk napsal(a):
Hello Mark,
Our security team was very concerned about the old ALSA FD. It provided too much access to the guts of ALSA.
I assume they will not like anything other than a plain "anon_inode:dmabuf". If it is a new FD, then the code would have to be reviewed. Even if it looked OK there might be some holes that we don't find. So it would probably be rejected.
Hello Phil,
My point is that the dma-buf -> sound pcm buffer maping interface is more complex, error prone and the code review/audit expensive than reusing the current code without any functionality or security benefits.
We can nicely restrict the file operations to allow to mmap only the pcm sound buffer and eventually, if we are too much paranoid (to bypass the the bitmap like permission checking as I suggested), we can create a special case for the Android usage to return the file descriptor with very restricted 'struct file_operations' with just the mmap and release callbacks. We can also change the name for this file descriptor to distinguish it from the "anon_inode:snd-pcm" (for example "anon_inode:snd-pcm-paranoid") to let SELinux do it's work properly.
The mmap implementation for the sound driver is few lines of the code (for the standard devices - very easy to review), so we cannot speak about security holes at all. If there is a problem with the kernel page allocation/management in the sound driver, there will be problem with dmabuf -> sound pcm buffer mapping, too (plus other problems caused by the concurrent access to the buffer which is managed /alloc/free/ by the sound driver - not dma-buf).
I cannot speak for our security team so I am working on setting up a meeting or conversation between Mark and Zach, our security expert.
Thanks. Let us know the result. Eventually, your security expert can freely join to our conversation here.
Jaroslav