On the contrary, clamd works out of the box as a service to scan files on demand, with the README explaining the rationale behind how the default configuration is written.
AFAICT there's nothing in the README.Debian or dpkg-reconfigure prompts that suggest there's a risk in leaving the socket publicly available as long as clamd is running as an unprivileged user.
Restricting access to that socket means restricting access to the service. We wouldn't tell users to restrict access to apache2 or mysqld sockets for instance on the ground that there's no other way to preserve their integrity.
The only mention of restricting access to the socket in the README is for when clamav is configured to run as root which it is not by default (I even doubt the claim in that errata that it may be needed in that case as the client can get clamd to scan any file they have read access to by passing it a fd they have opened to it (or the contents of the file over the socket. fdpass or stream)).
Even if we can imagine deployment scenarios where clamd is only used by postfix or ftpd to scan incoming emails/files, granting the "postfix" or "ftp" user (which themselves should also have minimum privileges) permission to shutdown clamd would make little sense.
Here no question is asked upon installing clamav-daemon (even when reconfiguring debconf with "Ignore questions with a priority less than: low"), and clamd is enabled and started straight away.
If the aim was for clamd to be configured by the user before it could be used safely, then I'd expect either the server not being enabled/started upon install or configured with a safer default (socket only available to clamav group for instance), and at least some form of debconf interaction upon install to point users in the right direction.
I see clamav-daemon is listed as a dependency for e2guardian or clamsmtp, I've not tested those, but from their description, it seems plausible that they also come with a default configuration and unlikely that they would instruct users to go and reconfigure clamd from its unsafe default.
Hi Seth, thanks for getting back on this.
On the contrary, clamd works out of the box as a service to scan files on demand, with the README explaining the rationale behind how the default configuration is written.
AFAICT there's nothing in the README.Debian or dpkg-reconfigure prompts that suggest there's a risk in leaving the socket publicly available as long as clamd is running as an unprivileged user.
Restricting access to that socket means restricting access to the service. We wouldn't tell users to restrict access to apache2 or mysqld sockets for instance on the ground that there's no other way to preserve their integrity.
The only mention of restricting access to the socket in the README is for when clamav is configured to run as root which it is not by default (I even doubt the claim in that errata that it may be needed in that case as the client can get clamd to scan any file they have read access to by passing it a fd they have opened to it (or the contents of the file over the socket. fdpass or stream)).
Even if we can imagine deployment scenarios where clamd is only used by postfix or ftpd to scan incoming emails/files, granting the "postfix" or "ftp" user (which themselves should also have minimum privileges) permission to shutdown clamd would make little sense.
Here no question is asked upon installing clamav-daemon (even when reconfiguring debconf with "Ignore questions with a priority less than: low"), and clamd is enabled and started straight away.
If the aim was for clamd to be configured by the user before it could be used safely, then I'd expect either the server not being enabled/started upon install or configured with a safer default (socket only available to clamav group for instance), and at least some form of debconf interaction upon install to point users in the right direction.
I see clamav-daemon is listed as a dependency for e2guardian or clamsmtp, I've not tested those, but from their description, it seems plausible that they also come with a default configuration and unlikely that they would instruct users to go and reconfigure clamd from its unsafe default.