apparmor DENIED freshclam and clamd access to openssl.cnf

Bug #1839767 reported by hambling
20
This bug affects 3 people
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/openssl.cnf.

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/openssl.cnf, which ends up with apparmor blocking the operation.

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/openssl.cnf file, and no warning will be generated by apparmor.

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(1588102725.538:18): apparmor="DENIED" operation="open" profile="/usr/bin/freshclam" name="/etc/ssl/openssl.cnf" pid=1864 comm="freshclam" requested_mask="r" denied_mask="r" fsuid=111 ouid=0
[ 60.201982] audit: type=1400 audit(1588102725.566:19): apparmor="DENIED" operation="open" profile="/usr/bin/freshclam" name="/etc/ssl/openssl.cnf" pid=1864 comm="freshclam" requested_mask="r" denied_mask="r" fsuid=111 ouid=0

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/bin/freshclam (657)

[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+dfsg-0ubuntu0.18.04.1
kern.log keeps reporting the following after installing clamav and clamav-daemon:

kernel: [ 10.851831] audit: type=1400 audit(1565467797.334:27): apparmor="DENIED" operation="open" profile="/usr/bin/freshclam" name="/etc/ssl/openssl.cnf" pid=962 comm="freshclam" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

kernel: [ 10.897174] audit: type=1400 audit(1565467797.382:28): apparmor="DENIED" operation="open" profile="/usr/sbin/clamd" name="/etc/ssl/openssl.cnf" pid=1101 comm="clamd" requested_mask="r" denied_mask="r" fsuid=112 ouid=0

Similar to: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1778812
Only seems like freshclam and clamd now need access to /etc/ssl/openssl.cnf

Looking at /etc/apparmor.d/usr.bin.freshclam
I have:
  @{PROC}/filesystems r,
  owner @{PROC}/[0-9]*/status r,

Do we need to add:
  /etc/ssl/openssl.cnf r,

To both usr.bin.freshclam and usr.bin.clamd ?

Tags: bitesize

Related branches

Revision history for this message
hambling (hambling) wrote :

I can confirm that adding
   /etc/ssl/openssl.cnf r,

to /etc/apparmor.d/usr.bin.freshclam and /etc/apparmor.d/usr.sbin.clamd

then run:
apparmor_parser -r /etc/apparmor.d/usr.bin.freshclam
apparmor_parser -r /etc/apparmor.d/usr.sbin.clamd

Makes the apparmor="DENIED" go away.
Also gets rid of the syslog warning - kernel: [ 11.240463] kauditd_printk_skb: 16 callbacks suppressed

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Thanks for filing this bug in Ubuntu.

This was fixed in 0.101.1+dfsg-1 (debian bug http://bugs.debian.org/913020), and is therefore fixed in Ubuntu eoan and later.diff --git a/debian/usr.bin.freshclam b/debian/usr.bin.freshclam
index 90490ac6..df5cb5be 100644
--- a/debian/usr.bin.freshclam
+++ b/debian/usr.bin.freshclam
@@ -4,10 +4,11 @@

 #include <tunables/global>

-/usr/bin/freshclam {
+/usr/bin/freshclam flags=(attach_disconnected) {
   #include <abstractions/base>
   #include <abstractions/nameservice>
   #include <abstractions/user-tmp>
+ #include <abstractions/openssl>

   capability setgid,
   capability setuid,
diff --git a/debian/usr.sbin.clamd b/debian/usr.sbin.clamd
index 91c67c45..45447594 100644
--- a/debian/usr.sbin.clamd
+++ b/debian/usr.sbin.clamd
@@ -7,6 +7,7 @@
 /usr/sbin/clamd {
   #include <abstractions/base>
   #include <abstractions/nameservice>
+ #include <abstractions/openssl>

   # LP: #433764:
   capability dac_override,

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
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I added a eoan task, and marked it as fix released, let's see how our tooling displays this bug.

Changed in clamav (Ubuntu Eoan):
status: New → Fix Released
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)
Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

[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/openssl.cnf.

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/openssl.cnf, which ends up with apparmor blocking the operation.

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/openssl.cnf file, and no warning will be generated by apparmor.

[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
$ sudo systemctl restart clamav-freshclam.service

Restarting the service is not strictly required, but guarantees that it will indeed try to open the /etc/ssl/openssl.cnf file. Now, we can grep for the warning message:

$ sudo dmesg | grep DENIED | grep freshclam
[ 60.177762] audit: type=1400 audit(1588102725.538:18): apparmor="DENIED" operation="open" profile="/usr/bin/freshclam" name="/etc/ssl/openssl.cnf" pid=1864 comm="freshclam" requested_mask="r" denied_mask="r" fsuid=111 ouid=0
[ 60.201982] audit: type=1400 audit(1588102725.566:19): apparmor="DENIED" operation="open" profile="/usr/bin/freshclam" name="/etc/ssl/openssl.cnf" pid=1864 comm="freshclam" requested_mask="r" denied_mask="r" fsuid=111 ouid=0

[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, especially because dh-apparmor is not available on bionic (and therefore is not used by clamav).

description: updated
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Disco is EOL, marking its task as such.

Changed in clamav (Ubuntu Disco):
status: Triaged → Won't Fix
description: updated
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Proposed package upload rejected

An upload of clamav to bionic-proposed has been rejected from the upload queue for the following reason: "Clobbered by security update 0.102.3+dfsg-0ubuntu0.18.04.1. Please re-base against the latest package version (if applicable).".

Revision history for this message
Robie Basak (racb) wrote :

This looks like a carefully and correctly put together SRU.

However, it seems like an awful lot of change (eg. refactoring of how the maintainer scripts handle AppArmor) for very little gain in a stable release. Normally we try to avoid refactoring of this kind in an SRU altogether. From https://wiki.ubuntu.com/StableReleaseUpdates:

"In line with this, the requirements for stable updates are not necessarily the same as those in the development release. When preparing future releases, one of our goals is to construct the most elegant and maintainable system possible, and this often involves fundamental improvements to the system's architecture, rearranging packages to avoid bundled copies of other software so that we only have to maintain it in one place, and so on. However, once we have completed a release, the priority is normally to minimise risk caused by changes not explicitly required to fix qualifying bugs, and this tends to be well-correlated with minimising the size of those changes. As such, the same bug may need to be fixed in different ways in stable and development releases."

Why is it necessary in this SRU to do this refactoring instead of just adding a single entry for /etc/ssl/openssl.cnf to the existing AppArmor profile?

Even then, I am still doubtful about the usefulness of this SRU. It might be different if this were for Focal as it is the current LTS. But this is for Bionic only. I am generally assuming that new deployments will be made on Focal. The majority of Bionic users who would notice the warning have probably already noticed it. For the few who might want the warning to go away, they can already do that by tweaking the AppArmor profile locally.

There is always a cost to an SRU - both in terms of regression risk, and the frustration/time/cost that users face when they find very large number of updates to install.

Assuming the only thing being fixed here is a warning to users in Bionic if they look in the logs, I'm not convinced that the benefit outweighs the cost, so I'm rejecting this SRU from the queue. Further discussion welcome if you think otherwise.

Changed in clamav (Ubuntu Bionic):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.