On Mon, 20 May 2019, Mikhail Morfikov wrote: > There's currently an abstraction *abstractions/audio* which > gives access to all devices/files that have something to do > with playing/capturing sounds. Many apps need only the > playback devices to play sounds. Other apps need also the > capture devices, so they could record sounds via a microphone. > Some people don't want to grant the access to the microphone, > for instance, in web browsers, or in a text-only messaging > app. I thought if I denied the access to the devices like > *pcmC[0-9]D[0-9]c* , the app, which wants to use the mic, > wouldn't be able to do it. But it looks like even adding in > the app's apparmor profile a rule that denies access to > anything under the /dev/snd/ dir doesn't really prevent > the app from accessing the microphone, or the soundcard. > > It looks like PulseAudio is involved here because when I > removed all the PA rules from the *abstractions/audio* file, > the app can't detect the soundcard anymore, and hence it > can't play or record any sound. > > So how to limit the mic access to certain apps using apparmor > profiles? Is that even possible, or am I only forced to grant > the app the full access to the soundcard? > > I'm currently using the linux kernel 5.1.2.
Currently when pulseaudio is involved, it will access the sound devices on behalf of your application to perform multiplexing/etc since many ALSA devices can't do that natively. This is also good since application only need to know about a high level API rather than details of specific devices, etc (which is good enough for simple playback/record). With pulseaudio, it is not possible to perform fine-grained mediation like record/playback since pulseaudio was not designed with this in mind. There are patches to pulseaudio that Ubuntu has carried for mediating this access on the old Ubuntu Phone and today with snapd. Upstream's answer seems to be that pipewire will be designed with this sort of thing in mind and make this easier. I've always liked the idea of apparmor gaining some syntax to specify rules that an audio server could query using libapparmor API, but this hasn't materialized (in part because pulseaudio is, aiui, in maintenance mode and the future are things like pipewire that weren't ready to use (this is starting to change)). As for devices in /dev/snd, my understanding (but I'm not an expert so feel free to correct me) is that the devices are not broken up between playback and capture and so simple rules that limit /dev/snd access are not sufficient (assuming you take pulseaudio out of the equation for your application). In short, today you can't do this without patching your pulseaudio and denying access to /dev/snd. In the future, pipewire should allow this sort of mediation, but I don't know OTOH what that will look like atm. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: PGP signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
