snapd 2.27.3+17.10 ADT test failure with linux 4.13.0-6.7

[Seth Forshee]

Testing failed on:
    amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/amd64/s/snapd/20170825_154928_33cfc@/log.gz
    i386: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/i386/s/snapd/20170825_150258_33cfc@/log.gz
    ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/ppc64el/s/snapd/20170825_141201_33cfc@/log.gz

[Seth Forshee (sforshee)]

+ CONNECTED_PATTERN=':avahi-observe +generic-consumer'
+ DISCONNECTED_PATTERN='^\- +generic-consumer:avahi-observe'
+ avahi_dbus_call='dbus-send --system --print-reply --dest=org.freedesktop.Avahi / org.freedesktop.Avahi.Server.GetHostName'
+ echo 'Then the plug is disconnected by default'
Then the plug is disconnected by default
+ MATCH '^\- +generic-consumer:avahi-observe'
+ snap interfaces
++ snap debug confinement
+ '[' strict = strict ']'
+ echo 'And the snap is not able to access avahi provided info'
And the snap is not able to access avahi provided info
+ generic-consumer.cmd dbus-send --system --print-reply --dest=org.freedesktop.Avahi / org.freedesktop.Avahi.Server.GetHostName
+ MATCH org.freedesktop.DBus.Error.AccessDenied
+ cat avahi.error
error: pattern not found, got:
Failed to open connection to "system" message bus: Failed to query AppArmor policy: Permission denied

[Seth Forshee (sforshee)]

+ su -l -c shutdown-introspection-consumer test
Failed to open connection to "system" message bus: Failed to query AppArmor policy: Permission denied

[Seth Forshee (sforshee)]

+ su -l -c test-snapd-system-observe-consumer.dbus-introspect test
Traceback (most recent call last):
  File "/snap/test-snapd-system-observe-consumer/6/bin/dbus-introspect", line 10, in <module>
    sys.exit(run())
  File "/snap/test-snapd-system-observe-consumer/6/bin/dbus-introspect", line 6, in run
    obj = dbus.SystemBus().get_object("org.freedesktop.hostname1", "/org/freedesktop/hostname1")
  File "/snap/test-snapd-system-observe-consumer/6/usr/lib/python3/dist-packages/dbus/_dbus.py", line 194, in __new__
    private=private)
  File "/snap/test-snapd-system-observe-consumer/6/usr/lib/python3/dist-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/snap/test-snapd-system-observe-consumer/6/usr/lib/python3/dist-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Failed to query AppArmor policy: Permission denied

[Seth Forshee (sforshee)]

+ su -l -c 'test-snapd-upower-observe-consumer.upower --dump' test

(upower:19791): UPower-WARNING **: Cannot connect to upowerd: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Failed to query AppArmor policy: Permission denied

[Tyler Hicks (tyhicks)]

The apparmorfs kernel query interface file has more restrictive file permissions in the upstream kernel versus what we've had in the Ubuntu sauce patches.

In Artful (Ubuntu 4.11.0-13.19-generic 4.11.12):
$ ls -al /sys/kernel/security/apparmor/.access
-rw-rw-rw- 1 root root 0 Aug 15 17:38 /sys/kernel/security/apparmor/.access

In linux-next (4.13.0-rc6-next-20170824):
$ ls -al /sys/kernel/security/apparmor/.access
-rw-r----- 1 root root 0 Aug 24 21:26 /sys/kernel/security/apparmor/.access

This means that the D-Bus session bus cannot perform AppArmor policy queries because it can't open the .access file.

[Tyler Hicks (tyhicks)]

@jjohansen are the more restrictive file permissions intentional? I see quite a few apparmorfs permissions changes between xenial and upstream:

-static struct aa_fs_entry aa_fs_entry_apparmor[] = {
- AA_FS_FILE_FOPS(".access", 0666, &aa_fs_access),
- AA_FS_FILE_FOPS(".stacked", 0666, &aa_fs_stacked),
- AA_FS_FILE_FOPS(".ns_stacked", 0666, &aa_fs_ns_stacked),
- AA_FS_FILE_FOPS(".ns_level", 0666, &aa_fs_ns_level),
- AA_FS_FILE_FOPS(".ns_name", 0666, &aa_fs_ns_name),
- AA_FS_FILE_FOPS("profiles", 0444, &aa_fs_profiles_fops),
- AA_FS_DIR("features", aa_fs_entry_features),
+static struct aa_sfs_entry aa_sfs_entry_apparmor[] = {
+ AA_SFS_FILE_FOPS(".access", 0640, &aa_sfs_access),
+ AA_SFS_FILE_FOPS(".stacked", 0444, &seq_ns_stacked_fops),
+ AA_SFS_FILE_FOPS(".ns_stacked", 0444, &seq_ns_nsstacked_fops),
+ AA_SFS_FILE_FOPS(".ns_level", 0666, &seq_ns_level_fops),
+ AA_SFS_FILE_FOPS(".ns_name", 0640, &seq_ns_name_fops),
+ AA_SFS_FILE_FOPS("profiles", 0440, &aa_sfs_profiles_fops),
+ AA_SFS_DIR("features", aa_sfs_entry_features),
        { }
 };

[John Johansen (jjohansen)]

sort of. The code was broken into patches and upstreamed piece meal, so the tighter restrictions when a give patch went it made sense. They also better reflect some of the internal permissions that were being enforced, ie. while profiles was 4444 you needed cap mac admin to actual see it. It looks like opening some of those back up dropped of the todo queue.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.13.0-11.12

---------------
linux (4.13.0-11.12) artful; urgency=low

  * linux: 4.13.0-11.12 -proposed tracker (LP: #1716699)

  * kernel panic -not syncing: Fatal exception: panic_on_oops (LP: #1708399)
    - s390/mm: fix local TLB flushing vs. detach of an mm address space
    - s390/mm: fix race on mm->context.flush_mm

  * CVE-2017-1000251
    - Bluetooth: Properly check L2CAP config option output buffer length

 -- Seth Forshee <email address hidden> Tue, 12 Sep 2017 10:18:38 -0500