snap.nextcloud.nextcloud-cron flooding syslog with AppArmor errors

[ge0rg]

Describe the bug

Every 15 minutes, the nextcloud-snap cronjob (rev28654 running on debian stable) is flooding dmesg with false positive(?) access denial messages:

[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559308): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559309): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559310): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559311): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559312): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559313): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559314): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559315): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559316): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:44:47 2021] audit: type=1400 audit(1639330399.292:559317): apparmor="DENIED" operation="ptrace" profile="snap.nextcloud.nextcloud-cron" pid=38271 comm="ps" requested_mask="read" denied_mask="read" peer="unconfined"
[Sun Dec 12 18:48:43 2021] kauditd_printk_skb: 215 callbacks suppressed

This and similar things have been reported in the past, but only as observations of othewise unrelated uprade issues (e.g. #1728 but going back as far as #42). As none of the issues are specifically about apparmor and nextcloud-cron, I'm opening this one.

It would be great to either stop the cron.php(?) script from doing the illegitimate access or to define a better matching apparmor rule.

There is also another access error from the renew-certs job:

[Sun Dec 12 18:48:43 2021] audit: type=1400 audit(1639330634.740:559533): apparmor="DENIED" operation="open" profile="snap.nextcloud.renew-certs" name="/proc/39436/mounts" pid=39436 comm="python2" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

To Reproduce

Steps to reproduce the behavior:

1. Install nextcloud-snap on Debian Stable
2. Keep the default background task scheduler to "cron"
3. Wait 15 minutes
4. See error in dmesg

Expected behavior

A default installation should come with apparmor rules that precisely match what it is allowed to do.

OS/snapd/snap version

# cat /etc/debian_version 
11.1
# snap version
snap    2.52.1
snapd   2.52.1
series  16
debian  11
kernel  4.19.0-11-amd64
# snap list nextcloud
Name       Version      Rev    Tracking       Publisher   Notes
nextcloud  22.2.3snap1  28654  latest/stable  nextcloud✓  -

Nextcloud is running behind Apache2 reverse-proxy on the /nc/ path of one of the apache-hosted domains.

Logs

Status of nextcloud-cron:

● snap.nextcloud.nextcloud-cron.service - Service for snap application nextcloud.nextcloud-cron
     Loaded: loaded (/etc/systemd/system/snap.nextcloud.nextcloud-cron.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-11-20 18:36:31 CET; 3 weeks 1 days ago
   Main PID: 12627 (nextcloud-cron)
      Tasks: 2 (limit: 9475)
     Memory: 51.8M
     CGroup: /system.slice/snap.nextcloud.nextcloud-cron.service
             ├─12627 /bin/sh /snap/nextcloud/28654/bin/nextcloud-cron
             └─45237 sleep 5m
                     
Warning: journal has been rotated since unit was started, output may be incomplete.

Other logs can be provided upon request.

[kyrofa]

I'm afraid you haven't seen much movement on this type of thing in the past, because here in the snap we have no control over:

1. What cron.php does
2. What the apparmor rule contains

[ge0rg]

Thanks for the response. I might not correctly understand this, but it looks like the apparmor rules are created by snap based on the interfaces that you have defined in nextcloud-snap, and there might be a way to define additional custom interfaces.

While you have no control over cron.php, it would probably make very much sense to assess what it is doing, in terms of apparmor rules, and provide an appropriate interface as part of this project.

[ribeck]

I'm having this very same issue on Ubuntu 20.04.3 - keen to find out if there is a workaround/fix to address the issue.
Thanks,

# snap version
snap    2.53.4
snapd   2.53.4
series  16
ubuntu  20.04
kernel  5.4.0-54-generic
# snap list nextcloud
Name       Version      Rev    Tracking       Publisher   Notes
nextcloud  22.2.3snap2  28713  latest/stable  nextcloud✓  -

[kyrofa]

there might be a way to define additional custom interfaces. [...] and provide an appropriate interface as part of this project.

I'm afraid you misunderstand how snap interfaces work. They're like android permissions, you select which pre-defined ones you're using and that's it. They allow us to poke predefined holes in the confinement model, but do not allow us to customize them. It would be handy if snapd supported silencing that type of thing unless you're debugging them, but it doesn't to the length of my knowledge. In general these things are non-fatal and are really not interesting. The software looks in a few places for this or that file, some of the places are off-limits, and that causes an apparmor log. It's normal. The software itself finds what it's looking for elsewhere (or doesn't), and typically carries on with its life.

If someone would like to dig into this to see if we should be using more interfaces or to see if upstream Nextcloud could be doing something differently to not trigger such things, I'd be happy to review any proposals. Just keep in mind that:

1. We don't want to make the surface area of the snap larger than necessary
2. We don't want the capabilities of the snap (in terms of confinement) larger than necessary

[hdmr14]

exactly same issue on Debian 11.2.

FYI, possibly missing process-control and/or system-observe at plugs?

[kyrofa]

Both of those break (2). Nothing actually requires those capabilities, so granting them just to silence a noisy log seems like it's asking for trouble.

[github-actions]

This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity.

[ge0rg]

The issue still exists. I'm not even sure what workarounds I could deploy to make my apparmor logging useful again.