13:28 < jdstrand> jhodapp: ok, so, unless there are implementation flaws (which are just bugs that we can fix later on), a malicious app with access to /android/micshm can't do anything to DoS the service or to record in the background, correct?
13:29 < jhodapp> jdstrand: correct, because there technically would be a reader on the Android side always open, but it won't be doing any reads unless triggered by kicking off the recording process
13:34 < jdstrand> jhodapp: could a malicious app could in theory interfere with an app that is already recording?
13:35 < jhodapp> jdstrand: in theory yes...I need to see if I could have the active reader/writer pair open the named pipe exclusively
13:36 < jhodapp> jdstrand: so that only one writer is allowed
13:49 < jdstrand> jhodapp: I think that would be a reasonable security improvement. I won't block adding the rule to policy though. pulseaudio itself isn't particularly great on this point aiui, and it too will need to be hardened
13:49 < jhodapp> jdstrand: indeed...exclusive pipe access would actually be an improvement over how AudioFlinger does it...I'm pretty sure it's using an unprotected pipe
This should no longer apply since the file permissions on the pipe are restrictive enough. An app would have to be in the android_media group or run as a user by the same name to be able to open the pipe. Currently the only two things that can do that right now are qtubuntu-camera and camera_service on the Android side. Is this exclusive enough to satisfy your requirements?