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 <fgou...@free.fr>