[Pkg-clamav-devel] Bug#884707: apparmor breaks clamdscan

[Francois Gouget]

Intrigeri wrote:
> Can you please provide the corresponding AppArmor denial logs you'll
> find in the Journal or in kern.log?

Here is a short extract:

Dec 26 12:30:29 amboise clamd[22031]: /mnt/storage1/cxinstallers/a3ebe77b3a63fdf0f3b1872110137bf0.Rift_LIVE_Patcher_setup.exe: Can't open file or directory ERROR
Dec 26 12:30:29 amboise kernel: [1014421.014749] audit: type=1400 audit(1514287829.691:24461): apparmor="DENIED" operation="open" profile="/usr/sbin/clamd" name="/mnt/storage1/cxinstallers/a3ebe77b3a63fdf0f3b1872110137bf0.Rift_LIVE_Patcher_setup.exe" pid=22031 comm="clamd" requested_mask="r" denied_mask="r" fsuid=118 ouid=1001
Dec 26 12:30:30 amboise clamd[22031]: /mnt/storage1/cxinstallers/e6623e9bcb0c3eeaedc5f4742ef0141e.qt-opensource-windows-x86-msvc2010-5.5.1.exe: Can't open file or directory ERROR
Dec 26 12:30:30 amboise kernel: [1014421.757351] audit: type=1400 audit(1514287830.434:24462): apparmor="DENIED" operation="open" profile="/usr/sbin/clamd" name="/mnt/storage1/cxinstallers/e6623e9bcb0c3eeaedc5f4742ef0141e.qt-opensource-windows-x86-msvc2010-5.5.1.exe" pid=22031 comm="clamd" requested_mask="r" denied_mask="r" fsuid=118 ouid=1001


> In the clamav-daemon's README.Debian I see:

Ah, I missed that.


> Yes, we're running an experiment about enabling AppArmor by default in 
> testing/sid since a couple months. I

Ok. It makes sense to do that as an experiment. So here is my feedback on 
the current configuration:

As far as I understand the apparmor profile is set up to only allow 
scanning email attachements, either from the email server of from some 
user email agent, or to scan the current user's files. That would be 
fine for a smartphone or tablet, or even a single-purpose computer or a 
locked down desktop meant for a large company's non-technical employees.

However I feel that it is way too restricting for a general purpose 
computer, particularly for a Linux distribution like Debian which is 
geared towards power users.

Also this apparmor configuration makes it impossible for clamdscan to work 
on files that are on usb keys since they are typically mounted in 
/media/<USER> and thus outside the locations allowed by the apparmor 
profile. Given the security risks presented by USB keys that's probably 
unwise.

If I understand the rationale behind the apparmor profile correctly, the 
goal is to limit the impact of clamd being compromised by a file it is 
asked to scan. However this apparmor profile will only push users to use 
clamscan instead of clamdscan and I doubt this is any better:

* clamd already runs in its own account. Only clamav's files belong to 
  that account so the damage clamd can do is limited by the fileystem 
  permissions. And they could be further limited by running clamd under 
  another account (e.g. clamd) with only read-only access to the clamav 
  files.

* In constrast clamscan runs in the user account. The system files are 
  still protected against it by the exact same filesystem permissions but 
  now all the user's files are vulnerable. This is all a ransomware app 
  really needs.


Finally this profile interferes with two of my use cases:

* The first one is that ClamAV is used as part of CrossOver, CodeWeavers' 
  version of Wine.
  http://www.winehq.org/
  https://www.codeweavers.com/products/crossover-linux

  One of the things that CrossOver adds is that it scans all files for 
  viruses before running (for Windows executables) or opening (for 
  documents, e.g. Word files) them in Wine. So what should CrossOver do 
  if the user opens a file in a location outside those allowed by the 
  apparmor profile? Silently open the file without scanning it, thus 
  betraying the trust of the user who thinks the anti-virus will stop 
  malicious files? Tell the user his anti-virus scanner is broken, which 
  the user is going to contest when he tests clamdscan on a file in his 
  directory? Tell the user to determine whether the file is infected by 
  himself? (as if he could)

* The second use case is the one which generated the log messages above.
  I have a script that monitors a bunch of Windows applications 
  installer URLs to make sure they are still valid and don't point to 
  viruses (or, more often than not, to detect ClamAV false positives). 
  Obviously the installers are cached and are not stored in my $HOME 
  (the installers total 127GB, and unlike my $HOME content they don't 
  need to be backed up, stored on a RAID disk or a fast SSD). Thus 
  clamdscan cannot scan them now. Sure that's not the kind of thing a 
  neophyte user would do but that's totally the kind of thing I would 
  expect a Debian user to do.


Workarounds:
* Modify the apparmor configuration obviously, though that workaround 
  is not applicable to the CrossOver case: (every Linux distribution's 
  apparmor configuration is going to be different, getting such a 
  modification working everywhere is likely going to be impractical, and 
  having a third-party package 'water down' the apparmor configuration 
  in some people's opinion presents obvious ethical issues).

* Use clamscan instead of clamdscan. However clamscan is really slow 
  which has a particularly significant impact on small files. For 
  instance on my laptop it takes over 9 seconds for clamscan to analyze 
  a 242 *bytes* file, while clamdscan does it in under 0.1 second (and 4 
  millisecond on the second run). This would also really impact the 
  CrossOver use case.

* Try to detect when clamdscan fails with an exit code of 2 and try again 
  with clamscan. This would limit the impact of clamscan's poor 
  performance. But this means introducing a lot of complication 
  everywhere that clamdscan is used.

* Use 'clamdscan --fdpass'. This completely bypasses the apparmor profile. 
  What are the security implications of that? As far as I can tell it's 
  not possible to reopen an existing fd with different access bits so 
  if clamdscan opens the file to be scanned in read-only mode, then clamd 
  should not be able to write to it. So why not make --fdpass the default?


-- 
Francois Gouget <fgouget at free.fr>