daemon-notify interface missing apparmor capabilities
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Confirmed
|
Medium
|
Unassigned |
Bug Description
The daemon-notify interface is currently not sufficient in order for a snap application to use `daemon: notify` in the snap.yaml. Specifically the following denials appear when trying to use `systemd-notify --ready --pid=$BASHPID` inside a snap with the daemon-notify, network, and network-bind interfaces plugged:
```
Apr 07 19:38:25 audit[28390]: AVC apparmor="DENIED" operation="open" profile=
Apr 07 19:38:25 audit[28390]: AVC apparmor="DENIED" operation="capable" profile=
Apr 07 19:38:25 kernel: audit: type=1400 audit(155468390
Apr 07 19:38:25 xenial-classic kernel: audit: type=1400 audit(155468390
```
I don't think the /proc/1/environ access is necessary (maybe quiet it with deny?), but adding the following to the apparmor policy will fix it:
```
capability net_admin,
capability sys_admin,
```
(if you just add net_admin, then systemd-notify will then proceed to try sys_admin and fail)
An example daemon shell script that doesn't currently work, but works with the above capabilities added is:
```
#!/bin/bash -e
sleep 10000 &
systemd-notify --ready --pid=$BASHPID
wait
```
Also, for some reason systemd-notify doesn't trigger these denials in devmode. I don't quite understand what it does in that situation to avoid needing those accesses.
This bug was explored in this pull request https:/ /github. com/snapcore/ snapd/pull/ 6697 but is has not been merged and indeed has been closed for now.
I'm marking it as confirmed / medium.