Seccomp failure resulting in no audio

This is probably a question for @jdstrand :slight_smile:

I’ve made a snap of MAME (the Multi Arcade Machine Emulator) which has no audio when strictly confined but plays audio fine when in devmode.

You can test this with snap install mame --candidate (with and without --devmode). mkdir -p ~/snap/mame/common/roms Then copy roms you have into ~/snap/mame/common/roms. Launch mame from the command line.

I notice this in the output of snappy-debug.security scanlog.

= Seccomp =
Time: Feb 22 10:07:21
Log: auid=1000 uid=1000 gid=1000 ses=4 pid=2492 comm="PulseHotplug" exe="/snap/mame/63/mame" sig=31 arch=c000003e 141(setpriority) compat=0 ip=0x7ff9a77c6d67 code=0x0
Syscall: setpriority
Suggestion:
* add one of 'browser-support, process-control' to 'plugs'

= Seccomp =
Time: Feb 22 10:07:21
Log: auid=1000 uid=1000 gid=1000 ses=4 pid=2492 comm="SDLAudioDev1" exe="/snap/mame/63/mame" sig=31 arch=c000003e 141(setpriority) compat=0 ip=0x7ff9a77c6d67 code=0x0
Syscall: setpriority
Suggestion:
* add one of 'browser-support, process-control' to 'plugs'

process-control and browser-support seem like the wrong things to be adding here. Is there some other solution?

Also, getting a ton of these, which may be related?

= AppArmor =
Time: Feb 22 10:07:21
Log: apparmor="DENIED" operation="open" profile="snap.mame.mame" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input18/capabilities/ev" pid=2492 comm="mame" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input18/capabilities/ev (read)
Suggestions:
* adjust program to not access '/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input18/capabilities/ev'
* adjust program to not access '/sys/devices/pci[0-9]*:[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/sound/card[0-9]*/input[0-9]*/capabilities/ev'

= AppArmor =
Time: Feb 22 10:07:21
Log: apparmor="DENIED" operation="open" profile="snap.mame.mame" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input19/capabilities/ev" pid=2492 comm="mame" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input19/capabilities/ev (read)
Suggestions:
* adjust program to not access '/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input19/capabilities/ev'
* adjust program to not access '/sys/devices/pci[0-9]*:[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/sound/card[0-9]*/input[0-9]*/capabilities/ev'

= AppArmor =
Time: Feb 22 10:07:21
Log: apparmor="DENIED" operation="open" profile="snap.mame.mame" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input20/capabilities/ev" pid=2492 comm="mame" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input20/capabilities/ev (read)
Suggestions:
* adjust program to not access '/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input20/capabilities/ev'
* adjust program to not access '/sys/devices/pci[0-9]*:[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/sound/card[0-9]*/input[0-9]*/capabilities/ev'

= AppArmor =
Time: Feb 22 10:07:21
Log: apparmor="DENIED" operation="open" profile="snap.mame.mame" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input21/capabilities/ev" pid=2492 comm="mame" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input21/capabilities/ev (read)
Suggestions:
* adjust program to not access '/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input21/capabilities/ev'
* adjust program to not access '/sys/devices/pci[0-9]*:[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/[0-9]*:[0-9]*:[0-9]*.[0-9]*/sound/card[0-9]*/input[0-9]*/capabilities/ev'

Finally, as a bonus, getting these which maybe related to joystick?

= AppArmor =
Time: Feb 22 10:07:21
Log: apparmor="DENIED" operation="open" profile="snap.mame.mame" name="/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2/capabilities/ev" pid=2492 comm="mame" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2/capabilities/ev (read)
Suggestions:
* adjust program to not access '/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2/capabilities/ev'
* adjust program to not access '/sys/devices/LNXSYSTM:[0-9]*/LNXSYBUS:[0-9]*/PNP[0-9]*C[0-9]*D:[0-9]*/input/input[0-9]*/capabilities/ev'


1 Like

This is: Setpriority bad system call

This needs investigating. Is the snap using alsa directly (it seems like it if it is probing the card for capabilities)? If so, what happens if you use pulseaudio instead?

This one should be allowed by the joystick interface since we have this rule:

/sys/devices/**/input[0-9]*/capabilities/* r,

Is the interface connected? As it happens, this will address the other apparmor denial even though it shouldn’t. This is documented in the snapd source:

# Allow reading for supported event reports for all input devices. See
# https://www.kernel.org/doc/Documentation/input/event-codes.txt
# FIXME: this is a very minor information leak and snapd should instead query
# udev for the specific accesses associated with the above devices.
/sys/devices/**/input[0-9]*/capabilities/* r,

I’m using the remote alsa part @lucyllewy made which (in theory) redirects the alsa calls to pulseaudio. Perhaps not all of them are captured? In theory it should “just work” with pulse only. I’ll give it a go rebuilding without any alsa stuff to see.

Ah, my bad. Looks like I didn’t have it connected. I assumed it was auto-connected.

It’s possible that the library used for joystick capabilities is hitting the soundcard ones too. IIRC, this was why joystick is broader than we’d prefer. When you test this build, please disconnect the joystick interface, test and report back-- if the denials are still there, I think we can assume it is a library that is taking ashotgun approach. If the denials go away, we can add these soundcard accesses to the alsa interface.

Either way, for your snap, simply connecting the joystick interface will make them go away.

I have a couple of SDL game snaps where I couldn’t get sound working through pulseaudio. Adding the joystick and process-control plugs (and connecting them) seems to have fixed audio in at least one of them. I had been getting apparmor and seccomp denials similar to the above. Will try rebuilding my other snaps.

Pulseaudio works without any such fiddling in some of my other SDL snaps.

This seems a bit broken.

1 Like

If anyone is interested in looking into this, I have a snap which exhibits the problem at https://github.com/mcphail/quakesnap . Without the joystick and process-control plugs connected, audio doesn’t work.

1 Like

Ok, confirmed. I’ve rebuilt the MAME snap, and revision 90 in the candidate channel now specifies process-control as one of the plugs. So doing the following will get audio working.

snap install mame
snap connect mame:process-control

So yes, that doesn’t seem right :slight_smile:

I can take a look at the quakesnap, but note that with MAME there were two issues: one with joystick and one with setpriority. It’s possible have one or the other not connected exercises different code paths (indeed, without process-control is setpriority is used the process will be killed).

I get both of those issues with the quake snap as well.

Except that we’re wanting to allow snaps that use the ALSA stack to work against pulseaudio, i.e. without the requirement to connect the alsa interface. This is because the alsa interface is not automatically connected because it provides much more access than is often desirable to grant, such as privileged access to the user’s session (IIRC).

My method does this, but it seems that hardware-observe privileges are often still required somewhere in the stack. This, despite having neutered ALSA meaning we now only need the pulseaudio interface for audio to flow.

Things that use pulseaudio shouldn’t need to interrogate the actual hardware-- that is what pulseaudio is for. If your part changes this, then we’ll have to look at that too. This snap still needs to be investigated and I’m not sure what is required.

This seems to work now. I have mame installed and can hear sound. This is probably related to the seccomp change from kill to eperm with logging.

FYI, I tried using a PiHut gamepad with this and it didn’t work due to: Joystick support for Cave Story snap (aka accessing joysticks via /dev/input/event*)