Hi,
I am following up on some denials which have been issued in my system running as follows :
root@1TXPB02:~# snap --versionsnap 2.28.5snapd 2.28.5series 16kernel 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ā
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 ?
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).
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.