Debugging Denials in snapd 2.28.5

[jenny.murphy]

Hi, I am following up on some denials which have been issued in my system running as follows :

root@1TXPB02:~# snap --version snap 2.28.5 snapd 2.28.5 series 16 kernel 4.4.0-96-generic An exisiting snap I have which accesses a serial port is not working as it used to

Can anyone provide information on the meaning of this denial : Oct 26 09:57:44 1TXPB02 kernel: [ 3962.522716] audit: type=1400 audit(1509011864.135:439): apparmor=“DENIED” operation=“open” profile="/usr/lib/snapd/snap-confine" name="/sys/module/rfkill/uevent" pid=11774 comm=“snap-confine” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

Also this one, which is specific to my snap: [ 3247.437500] audit: type=1400 audit(1509011149.775:418): apparmor=“STATUS” operation=“profile_replace” profile=“unconfined” name=“snap.epi-zaphost.zaphost” pid=9834 comm=“apparmor_parser”

And these which are specific to a snap I interface with: [ 3247.493001] audit: type=1400 audit(1509011149.831:419): apparmor=“STATUS” operation=“profile_replace” profile=“unconfined” name=“snap.caracalla.hibernate-handler” pid=9844 comm=“apparmor_parser” [ 3247.507823] audit: type=1400 audit(1509011149.843:420): apparmor=“STATUS” operation=“profile_replace” profile=“unconfined” name=“snap.caracalla.hook.prepare-device” pid=9846 comm=“apparmor_parser”

[ogra]

the profile-replace status messages are normal when the profiles get updated, you can ignore them.

the rfkill denial is a bit strange though, technically the network-control interface should allow access to rfkill, but i do not see the specific /sys/module/rfkill path allowed in there. also the denial seems to come from snap-confine, not from any application snap … probably @zyga-snapd or @jdstrand could help here ?

[jenny.murphy]

Also just to check, are dBus denials included yet in
/snap/bin/snappy-debug.security ?

[jdstrand]

Yes, as of this week there is preliminary support (the denials will now be shown and snappy-debug will make a few suggestions, but they may not be complete depending on the denial. The nice thing about dbus denial is it is usually very clear what service the snap is being denied access to, and which interface to choose based on that).

[jdstrand]

@jenny.murphy

Can anyone provide information on the meaning of this denial :

Oct 26 09:57:44 1TXPB02 kernel: [ 3962.522716] audit: type=1400 audit(1509011864.135:439): apparmor=“DENIED” operation=“open” profile="/usr/lib/snapd/snap-confine" name="/sys/module/rfkill/uevent" pid=11774 comm=“snap-confine” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

snapd 2.28.5 now udev tags all devices so they may be correctly added to the snap’s device cgroup. This denial is being triggered by snap-confine’s udev querying. This is a bug in it’s policy that I’ll submit a PR for 2.29.

[jdstrand]

The uevent denial has a fix in https://github.com/snapcore/snapd/pull/4098 for the uevent denial. I’ve requested this for 2.29.