apparmor failure on udev with opengl interface

[Alan Pope 🍺🐧🐱 🦄]

With a mame snap I made, I get this with "snappy-debug.security scanlog mame"

Time: Jun 6 20:55:31
Log: apparmor="ALLOWED" operation="open" profile="snap.mame.mame" name="/run/udev/data/+pci:0000:00:02.0" pid=2777 comm="mame64" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /run/udev/data/+pci:0000:00:02.0 (read)
Suggestions:
* adjust program to use $SNAP_DATA
* adjust program to use /run/shm/snaps/$SNAP_NAME/$SNAP_REVISION

[Jamie Strandboge (jdstrand)]

I think what is happening is this comes up when the app is trying to use the opengl device. What are the contents of the file? Ie:

$ cat "/run/udev/data/+pci:0000:00:02.0"

Regardless of if it is opengl or something else, the proper way to fix this is to query udev to get the files in /run/udev based on the device file used in /dev. In this manner we can give precise access to files in /run/udev/data.

In the meantime, it is possible to add this glob rule:
  /run/udev/data/** r,

That constitutes an information leak though as there can be sensitive data in this directory (eg, MAC addresses, hardware identifiers, information for data mining, etc) so we should plan on querying udev for precise access instead of always keeping the glob rule.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

alan@gort:~$ cat "/run/udev/data/+pci:0000:00:02.0"
I:3845078
E:ID_PCI_CLASS_FROM_DATABASE=Display controller
E:ID_PCI_SUBCLASS_FROM_DATABASE=VGA compatible controller
E:ID_PCI_INTERFACE_FROM_DATABASE=VGA controller
E:ID_VENDOR_FROM_DATABASE=Intel Corporation
E:ID_MODEL_FROM_DATABASE=Broadwell-U Integrated Graphics
E:FWUPD_GUID=0x8086:0x1616

[Jamie Strandboge (jdstrand)]

Ok, this confirms my suspicion and I stand by my querying udev comment in opengl (I brought this up elsewhere and its known).

@zyga - what kind of time frame can we expect on querying udev? I suspect this denial is actually non-fatal, but it would be good to get it cleaned up.

[Zygmunt Krynicki (zyga)]

Hmm, I don't really know. Can you give me some more information.

1. What are we asking udev about?
2. What is the key / attribute used to look this up in udev?
3. Do we have a sample snap to test this?
4. Does this affect all GPU vendors equally?

I think that after we have hook support the opengl interface can use a
hook where we'd ask udev about 1) and 2) and use this information to
grant plug side appropriate permissions.

In the meantime I agree that we should use a blank check that we
revoke as soon as possible.
ZK

On Mon, Jun 6, 2016 at 10:33 PM, Jamie Strandboge <email address hidden> wrote:
> Ok, this confirms my suspicion and I stand by my querying udev comment
> in opengl (I brought this up elsewhere and its known).
>
> @zyga - what kind of time frame can we expect on querying udev? I
> suspect this denial is actually non-fatal, but it would be good to get
> it cleaned up.
>
> ** Changed in: snappy
> Status: New => Confirmed
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snappy.
> https://bugs.launchpad.net/bugs/1589671
>
> Title:
> apparmor failure on udev with opengl interface
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1589671/+subscriptions

[Alan Pope 🍺🐧🐱 🦄 (popey)]

This is the snap I am testing.

[Jamie Strandboge (jdstrand)]

@zyga, I answered your question in the modem-manager PR: https://github.com/snapcore/snapd/pull/1226/files#r66140667

[Jamie Strandboge (jdstrand)]

Another user found this:
/sys/devices/system/node/node0/meminfo r,
/run/udev/data/+pci:0000:00:02.0 r,

Rather than waiting on the udev querying, I'll add some lenient rules with FIXMEs to unblock people.

[Jamie Strandboge (jdstrand)]

This is merged and will be in 2.0.9.

[Jamie Strandboge (jdstrand)]

This was fixed in 2.0.9.