apparmor regression blocking freshclam process info

[Jean-Pierre van Riel]

Very much like, but a new regression with the same issue

https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/645061

The following IS in /etc/apparmor.d/usr.bin.freshclam

@{PROC}/filesystems r,
owner @{PROC}/[0-9]*/status r,

And

$ ps -u clamav -f | more
UID PID PPID C STIME TTY TIME CMD
clamav 1348 1 0 08:38 ? 00:00:02 /usr/bin/freshclam -d --foregrou
nd=true
$ ls -l /proc/1348/status
-r--r--r-- 1 root root 0 Jan 25 08:38 /proc/1348/status

Shows that root owns the status file, not the clamav user.

Hence denied.

[Andreas Hasenack (ahasenack)]

Confirmed on xenial:
Aug 28 12:04:58 nsn7 kernel: [11101.452884] audit: type=1400 audit(1503932698.778:169): apparmor="DENIED" operation="open" profile="/usr/bin/freshclam" name="/proc/27262/status" pid=27262 comm="freshclam" requested_mask="r" denied_mask="r" fsuid=136 ouid=0

(...)
bytecode.cvd updated (version: 309, sigs: 69, f-level: 63, builder: bbaker)
Querying bytecode.309.82.1.0.9B624057.ping.clamav.net
Database updated (6309018 signatures) from db.local.clamav.net (IP: 155.98.64.87)
ERROR: NotifyClamd: Can't find or parse configuration file /etc/clamav/clamd.conf

Not sure if the above error is related, though. A follow-up run doesn't fail, but probably because the db is up-to-date on disk.

[Andreas Hasenack (ahasenack)]

Sorry, slight brainfart. I didn't have clamd installed.

That being said, the apparmor error is confirmed. I got rid of it by using:

  @{PROC}/@{pid}/status r,

I'll check https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1658239 which could be related.

[Robie Basak (racb)]

I can't reproduce this on Bionic today. I'm expecting to see a denial in /var/log/kern.log or dmesg after installing the clamav package, but I see none. I also tried stopping the clamav-freshclam service and running "sudo freshclam" manually, but I still don't see a denial.

/etc/apparmor.d/usr.bin.freshclam includes abstractions/base, which contains "@{PROC}/@{pid}/{maps,auxv,status} r". So I'd expect the open call to work now based on Andreas' comment 1 above.

I did manage to see a denial message in Xenial though. Here, I don't see "status" in /etc/apparmor.d/abstractions/base.

Therefore I believe this is fixed in Bionic.

It seems to me that the best way to fix this would be to add "@{PROC}/@{pid}/{maps,auxv,status} r" to /etc/apparmor.d/abstractions/base in an SRU to the apparmor package Xenial?

Having said that, since it's just a warning for clamav and doesn't cause a functional problem, I'm not sure an SRU would be justified.

[Robie Basak (racb)]

Bug 1658239 is relevant. If we want to SRU apparmor in Xenial for this, that's probably the right bug to use.

[Robie Basak (racb)]

> Having said that, since it's just a warning for clamav and doesn't cause a functional problem, I'm not sure an SRU would be justified.

To re-iterate: this is fixed in Bionic. It still affects Xenial, but unless there's a functional reason this is a problem for users, rather than just a log message, I see no need to fix this in Xenial. If anyone has a justification, please comment.