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

[intrigeri]

Control: affects -1 - clamav-daemon
Control: reassign -1 clamav-daemon

Hi,

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

Thanks.

Reassigning to clamav-daemon, that ships the
/etc/apparmor.d/usr.sbin.clamd profile, then.

> So here is my feedback on the current configuration: […]

Thanks for thinking this through. I'm not knowledgeable with ClamAV so
I'll stick to general comments and recommendations based on my
experience maintaining AppArmor support in Debian and Tails.
I'll leave it to the ClamAV maintainers to decide what they think is
best for Debian and its users.

Some more data points for context:

 * Ubuntu has been shipping this AppArmor profile since April, 2009.

 * In the Ubuntu bug tracker I see exactly one AppArmor-related bug:
   https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1659223

 * Since AppArmor has been enabled by default in Debian testing/sid
   (mid-November, 2017) one single user reported a regression caused
   by this change with clamd.

>From this I think we can safely infer that the clamd AppArmor profile
works just fine for the overwhelming majority of its users. Sadly, in
general it's the best we can do wrt. AppArmor: even once the huge
majority of users' needs are covered, any path-based sandboxing
approach (such as AppArmor) will definitely break for a minority of
users who use the software in a custom way. In general the best we can
do to accommodate these needs is document how power users can adjust
the AppArmor policy to their needs (or fully disable it if they wish
so:  Debian has never shipped with AppArmor enabled by default yet, so
if a few users have do disable clamd confinement it's not
a regression). The alternatives are not very compelling, they are
basically: either give up on path-based LSM entirely or make the
AppArmor policy wide enough to accommodate all kinds of needs; in both
cases, we lose security benefits of the majority of users for whom the
current profile would work just fine, which is sad.

So with my AppArmor in Debian maintainer hat, I would find it
reasonable if the clamav-daemon maintainers decided to leave it as-is,
possibly improving a little bit the existing documentation in
README.Debian to provide better guidance to power-users whose use case
is not supported by the current AppArmor policy. I'm happy to help
with the latter part if needed.

> * 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?

I'm not knowledgeable enough wrt. ClamAV to have an informed opinion
on this idea but I find it interesting :)

Cheers,
-- 
intrigeri