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

[Sebastian Andrzej Siewior]

On 2018-01-07 14:59:54 [+0100], intrigeri wrote:
> Hi,
Hi,

> Francois Gouget:
> /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.

I think we included it on their request.

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

this does not look related to this bug.

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

So looking at this I think it is just fine. clamd should only access
specific files which includes files from postfix & exim spool
directories. By allowing accessing everything it kind of defeats its
purpose (however I am not sure how that $HOME rule works).
The rules file ends with
| # Site-specific additions and overrides. See local/README for details.
| #include <local/usr.sbin.clamd>

Maybe if you could provide some info how to add a local rule to enable
clamd to read everything, that would be nice.

> > * Use 'clamdscan --fdpass'. This completely bypasses the apparmor profile. 
> >   What are the security implications of that? As far as I can tell it's 
It does not completely bypass the the profile because the profile does
not forbid fd-passing. It could :). So clamd it not allowed to open
random files on its own but it can open any file that the user (at the
other end of the socket) is able to.

> >   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 :)

If you want to have it used / enabled by default then I could ask
upstream what they do think about it.
From the build logs, fdpassing is supported on linux & kfreebsd so it
should work everywhere within Debian.
 
> Cheers,

Sebastian