apparmor DENIED freshclam and clamd access to openssl.cnf
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
clamav (Debian) |
Fix Released
|
Unknown
|
|||
clamav (Ubuntu) |
Fix Released
|
Undecided
|
Sergio Durigan Junior | ||
Bionic |
Won't Fix
|
Low
|
Sergio Durigan Junior | ||
Disco |
Won't Fix
|
Low
|
Unassigned | ||
Eoan |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
After installing clamav on Ubuntu bionic, the clamav-freshclam unit is started. This service is responsible for automating the update process of virus databases.
In order to perform its job, clamav-freshclam links against libssl and uses it to validate SSL certificates when updating its virus definitions. This means that it also needs to be able to read the file /etc/ssl/
The current clamav shipped in Ubuntu bionic does not contain the proper directives necessary to instruct apparmor that clamav-freshclam and clamd are allowed to open the file /etc/ssl/
Fortunately, clamav-freshclam is able to proceed and finish the operation without problems, but the warning can be misleading to a user and give the impression that no certificate validation is being performed, for example.
The fix is very simple and contained: we just need to add the proper openssl abstractions to the clamav-freshclam and clamd apparmor profiles. This makes sure that both processes will be able to properly read the /etc/ssl/
This update also fixes the fact that clamav-freshclam runs unconfined on its first install, because its apparmor profile is loaded after the service has been started. Part of this fix involves adopting dh-apparmor and getting rid of the hand-crafted apparmor code that currently lives in the *.postinst files.
[Test Case]
In order to reproduce the bug, one can do:
$ multipass launch -n clamav-bug1839767 bionic
$ multipass shell clamav-bug1839767
When inside the VM:
$ sudo apt install clamav
Now, we can grep for the warning message:
$ sudo dmesg | grep DENIED | grep freshclam
[ 60.177762] audit: type=1400 audit(158810272
[ 60.201982] audit: type=1400 audit(158810272
Notice also that the clamav-freshclam daemon is running in unconfined mode, even though it does have an apparmor profile installed:
$ sudo aa-status
...
1 processes are unconfined but have a profile defined.
/usr/
[Regression Potential]
This change is trivial and self-contained, and as such it is not likely to cause regressions on current setups.
An obvious potential (albeit unlikely) issue is the fact that we will be introducing a package built using the current libraries and headers that are available in bionic today, instead of the ones available back when the current release of clamav was built.
Another issue might arise if the user has edited the clamav-freshclam and/or clamd apparmor profiles by hand in order to mitigate the warning on their systems. An upgrade problem could happen in this case if dpkg has problems replacing the user-modified file by the new file shipped by the package, because dh-apparmor was not used by clamav until this SRU.
A fact worth noting is that, in this update, clamav will start using dh-apparmor to handle its appamor profiles, while so far it has been using a hand-crafted code inside the *.postinst files. This could have the side-effect of introducing dh-apparmor specific problems that might exist today, but overall I believe the adoption of a debhelper utility makes the package much more robust.
[Other Info]
Finally, something else worth mentioning is the fact that the *.postrm scripts still carry apparmor-specific code to manually remove the profiles when purging the package, which can be considered a duplicate effort of what dh-apparmor already does. The justification for leaving this bit as-is is that it also happens in focal and groovy, which means that this SRU would have to apply to them as well if we were to fix this small problem.
[Original Description]
A similar bug seems to have been reported before but keeps returning.
I'm seeing it on an new install of bionic server 18.04 clamav version: 0.100.3+
kern.log keeps reporting the following after installing clamav and clamav-daemon:
kernel: [ 10.851831] audit: type=1400 audit(156546779
kernel: [ 10.897174] audit: type=1400 audit(156546779
Similar to: https:/
Only seems like freshclam and clamd now need access to /etc/ssl/
Looking at /etc/apparmor.
I have:
@{PROC}
owner @{PROC}
Do we need to add:
/etc/
To both usr.bin.freshclam and usr.bin.clamd ?
Related branches
- Bryce Harrington (community): Approve
- Canonical Server Core Reviewers: Pending requested
-
Diff: 194 lines (+44/-62)7 files modifieddebian/changelog (+18/-0)
debian/clamav-daemon.postinst.in (+0/-25)
debian/clamav-freshclam.postinst.in (+18/-37)
debian/control (+1/-0)
debian/rules (+5/-0)
debian/usr.bin.freshclam (+1/-0)
debian/usr.sbin.clamd (+1/-0)
no longer affects: | clamav (Ubuntu Eoan) |
Changed in clamav (Ubuntu Bionic): | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in clamav (Ubuntu Disco): | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | added: bitesize |
Changed in clamav (Debian): | |
status: | Unknown → Fix Released |
Changed in clamav (Ubuntu): | |
assignee: | nobody → Sergio Durigan Junior (sergiodj) |
Changed in clamav (Ubuntu Bionic): | |
assignee: | nobody → Sergio Durigan Junior (sergiodj) |
description: | updated |
description: | updated |
I can confirm that adding ssl/openssl. cnf r,
/etc/
to /etc/apparmor. d/usr.bin. freshclam and /etc/apparmor. d/usr.sbin. clamd
then run: d/usr.bin. freshclam d/usr.sbin. clamd
apparmor_parser -r /etc/apparmor.
apparmor_parser -r /etc/apparmor.
Makes the apparmor="DENIED" go away.
Also gets rid of the syslog warning - kernel: [ 11.240463] kauditd_printk_skb: 16 callbacks suppressed