ClamAV AppArmor profiles do not allow OnAccess scanning

[Jeff]

Ubuntu 18.04 + clamav-* 0.100.3+dfsg-0ubuntu0.18.04.1

The auditd log info below[1][2] shows what I believe to be a bug in the 0.100.3 AppArmor profiles included with the Ubuntu packages "clamav-daemon" and "clamav-freshclam". The included profiles do not allow the proper execution of clamd.

  jblaine@ub18test:~$ sudo dpkg -S /etc/apparmor.d/usr.sbin.clamd
  clamav-daemon: /etc/apparmor.d/usr.sbin.clamd
  jblaine@ub18test:~$ sudo dpkg -S /etc/apparmor.d/usr.bin.freshclam
  clamav-freshclam: /etc/apparmor.d/usr.bin.freshclam
  jblaine@ub18test:~$

Specifically, the denied items[1][2] appear to disallow OnAccess scanning:

1. clamd complains that it needs to run as root:

  Sep 4 11:33:50 ub18test clamd[55172]: ScanOnAccess: fanotify_init failed: Operation not permitted
  Sep 4 11:33:50 ub18test clamd[55172]: ScanOnAccess: clamd must be started by root

2. clamd *is* running as root (required for OnAccess scanning, configured this way intentionally by me):

  root 55172 1 81 16:33 ? 00:00:44 /usr/sbin/clamd --foreground=true

If I disable the clamd AppArmor profile and restart the service, the OnAccess scanning works:

  jblaine@ub18test:~$ sudo ln -s /etc/apparmor.d/usr.sbin.clamd /etc/apparmor.d/disable/
  jblaine@ub18test:~$ sudo sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.clamd
  jblaine@ub18test:~$ sudo systemctl restart clamav-daemon
  jblaine@ub18test:~$

  ...
  Sep 4 12:19:21 ub18test clamd[4299]: ScanOnAccess: preventing access attempts on malicious files.
  Sep 4 12:19:21 ub18test clamd[4299]: ScanOnAccess: Max file size limited to 104857600 bytes
  Sep 4 12:19:21 ub18test clamd[4299]: ScanOnAccess: Protecting directory '/home' (and all sub-directories)

Regards,
Jeff Blaine

FOOTNOTES:

1. clamd issues found in auditd log:

node=ub18test type=AVC msg=audit(1567542270.923:11512):
apparmor="DENIED" operation="capable" profile="/usr/sbin/clamd"
pid=54842 comm="clamd" capability=2 capname="dac_read_search"

node=ub18test type=AVC msg=audit(1567542271.039:11517):
apparmor="DENIED" operation="open" profile="/usr/sbin/clamd"
name="/etc/ssl/openssl.cnf" pid=54858 comm="clamd" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0

node=ub18test type=AVC msg=audit(1567542315.684:11521):
apparmor="DENIED" operation="capable" profile="/usr/sbin/clamd"
pid=54858 comm="clamd" capability=21 capname="sys_admin"

2. freshclam issues found in auditd log:

node=ub18test type=AVC msg=audit(1567543073.345:97): apparmor="DENIED"
operation="open" profile="/usr/bin/freshclam"
name="/etc/ssl/openssl.cnf" pid=736 comm="freshclam" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0

node=ub18test type=AVC msg=audit(1567543073.729:103): apparmor="DENIED"
operation="capable" profile="/usr/bin/freshclam" pid=736
comm="freshclam" capability=2 capname="dac_read_search"

node=ub18test type=AVC msg=audit(1567543073.729:103): apparmor="DENIED"
operation="capable" profile="/usr/bin/freshclam" pid=736
comm="freshclam" capability=1 capname="dac_override"

[Paride Legovini (paride)]

Thanks for your report and for providing the relevant logs. This can be reproduced fairly easily by installing the auditd and clamav packages (unprivileged LXD containers can't run auditd, I used a VM). The OnAccess scanning mode can be enabled by setting

  LocalSocketGroup root
  User root
  ScanOnAccess true

in /etc/clamav/clamd.conf and by running `clamd --foreground` as root. The auditd log will show a message like

  apparmor="DENIED" operation="capable" profile="/usr/sbin/clamd"
  pid=54858 comm="clamd" capability=21 capname="sys_admin"

and clamd won't start in OnAccess mode. I confirm that disabling the clamd AppArmor profile makes it work. As the bug report states, OnAccess doesn't work with the AppArmor profile we ship.

OnAccess scanning needs to call fanotify_init(2), which in turn needs the sys_admin capability. This capability is very wide-ranging, see capabilities(7). Before allowing it the security implications should be evaluated.

Some notes:

1. I don't think flashclam is involved in this specific issue, but the reason for the AppArmor denials shown in the bug description (footnote 2) should probably be investigated too.

2. The only missing capability that prevents clamd from starting in OnAccess mode seems to be the 'sys_admin' capability. In my testing I've got no errors about 'dac_read_search', while the denied "open /etc/ssl/openssl.cnf" was there but apparently didn't cause any harm.

3. Running the daemon as root is clearly not a good idea. This setup would be better handled by giving cap_sys_admin to /usr/sbin/clamd or to the clamav user. I didn't try this setup, but it should be feasible.

[Paride Legovini (paride)]

Giving a process cap_sys_admin is effectively giving it root, which is something we don't want to do. This means there is no good way to support OnAccess by default.

Allowing cap_sys_admin via AppArmor also kind of defeats the purpose of AppArmor, as the capability is so wide, so I doubt the change will be integrated in the default AppArmor profile.

Unfortunately there is no good solution here. The best we can do is to document that OnAccess needs root (= cap_sys_admin) and what is the best way to implement this setup. Running the daemon with uid=0 is certainly not the right thing to do for a number of reasons. Giving cap_sys_admin to /usr/sbin/clamd could work, but we need to ensure the setting will survive the package upgrades. (I gave a shot to `setcap cap_sys_admin+ep /usr/sbin/clamd` and it still failed to run fanotify_init(), but I'm pretty sure this is feasible.)

[John Johansen (jjohansen)]

Let me slightly revise what legovini wrote (and appologies to legovini who was just passing on my less than adequate explanation).

It is true that giving cap sys_admin is effectively giving a process root. That doesn't mean we don't do it, but we do it very carefully, and only after review of the use cases. It is also true that there is no good solution to separate out the root functionality that cap sys_admin grants because the kernel conflates several different permissions under cap sys_admin.

The apparmor confinement will still apply even after granting cap sys_admin. But it is somewhat weakened. Just how much will depend on other parts of the profile. And having the profile will be better than not having it as even weakened it can split appart some of the broad permissions granted by cap sys_admin.

There is no point in having broken packages due to security, it just upsets users and leads to users turning off security which is the worst possible result.

So the question is how useful is clamav when not using OnAccess mode?

If we are going to allow OnAccess,
Is it by default, or an optional configuration?
And what is the best way to allow cap sys_admin?

If necessary the apparmor profile can be updated to allow cap sys_admin, however it is certainly more desirable (from a security perspective) to make it optional behind a tunnable or have it commented out by default.

[Robert Dinse (nanook)]

Well this bug now affects at least two persons as I am also encountering it on ubuntu 20.04.

[Christian Ehrhardt  (paelzer)]

Trying to revive some old bugs that seem forgotten for too long.

I think the discussion came to a point where:

1. The apparmor rule that would need to be added is clear

2. Adding it by default is considered not safe

3. The fix therefore can only be to ensure users that want to use it this way are aware
   - Paride mentioned adding things to docs
     The packages readme already mentions that in general (but not the specific case)
     "If your system uses apparmor, please note that the shipped enforcing profile
      works with the default installation, and changes in your configuration may
      require changes to the installed apparmor profile. ..."
   - I have not found any mention of ScanOnAccess in the man page or the HTML docs

4. It is definitely desirable to add this apparmor rule in a way not revoked by package upgrades
   That can be done with the common pattern of local overrides.
   See /etc/apparmor.d/local/README
   For this case to allow it would be like:
     echo "capability sys_admin," >> /etc/apparmor.d/local/usr.sbin.clamd

As others outlined before "just allowing it by default" seems no option.
And maybe because no one felt as if "we could do much" the activity dropped.
But we should consider adding a hint how to easily do so (see #4 above) to documentation (IMHO in descending usefulness):

- Add comment about ScanOnAccess and apparmor in /etc/clamav/clamd.conf
- man page add section about apparmor (as people look there first)
- Readme.debian (as example along the already existing entry about apparmor)

Debian uses apparmor as well now, it might be worth to do the changes there directly so that everyone benefits.

That task is small (bitesize) but also low prio - so that is how I'd retriage the bug for now.

[Michał Małoszewski (michal-maloszewski99)]

I've decided to file Debian bug report first:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043428

[Bryce Harrington (bryce)]

Michal took a good shot at preparing an update, but won't be working further on it. We think a bit more work is needed, and also would like to get input from Debian, so will postpone it until one of those two things occur.