I'm uncertain what the policy was on non-root users doing this but wanted to share a patch we're using.

Possibly this needs to be a config file setting but I lack the knowledge to add that to this patch.

It should probably be a config option if we take this patch. Thank you for sharing it. I will bring it up with the team in our next standup.

We're also considering giving ClamD a REST (HTTP) API and have had some discussion about implementing certificate-based authentication at that time. But we need to dedicate some time to plan what to do with an application sandbox prototype developed by my colleague @zaddach which may necessitate an overhaul or full Rust re-write of ClamD, or simply a new server program as an alternative to ClamD. That decision will tie in with what we do for the socket API for ClamD and ultimately if we should use this patch with a new config option, or if we should find a different mechanism to authorize administrative-type commands.

Looks like the build fails on Mac & Windows, and fails a test on Linux with:

6: Wed Nov 3 20:27:22 2021 -> Command invalid for non root users: STATS

I'm closing this PR due to inactivity, and because I do not believe this is the right solution to prevent other users on the local box from running these commands.

Outside of the build issues on Mac and Windows, this solution would prevent regular users from using the STATS and SHUTDOWN commands when running clamd as themselves. The STATS command, in particular, is used by clamdtop and there is a strong use case for this program whether clamd is run as the current user or when run as the clamav user.

But this also does not prevent anyone who can access the TCP socket from running these commands when clamd is listening to the TCP socket. So it is not a full solution for the unauthorized-shutdown concern.

The only solution I can think to allow users to run scans but prevent them from running these commands is to add clamd.conf config options to disable the SHUTDOWN and STATS commands (separately). In this way the admin can choose if they are comfortable with allowing anyone who can access the socket to issue those commands. For this approach I'm not opposed to having support for the SHUTDOWN command to be default-off, but the STATS command support should be on by default, in order for clamdtop to function.

An additional note regarding the STATS command: In case you're concerned that an unauthorized user may index another user's private directory by running clamdscan -r /home/other_user, I should remind you that you should not run clamd as the root user or as another high privileged user. clamd is best run as your own user or better yet as a lower privileged user like the clamav service account. If running clamd as your own user, you can secure a unix socket by locating it within your home directory. The clamdscan --fdpass (or clamonacc --fdpass) options will allow you to have clamd scan files that the clamav user cannot open on its own.

Finally, for administrators that wish to run a clamd server and allow some local users to perform scans while denying all other users from issuing clamd commands, they should use the LocalSocket option in combination with the LocalSocketGroup and LocalSocketMode options.

Take for example this scenario. An admin may wish to configure clamonacc to monitor specific directories on the system such as as a webserver upload directory, or user home directories or downloads directories. The clamonacc process would run as root. The clamd process would run as the low-privileged clamav service account user, or start as root and drop to run as the clamav user. In the clamd.conf, something like this would be set:

/var/lib/clamav/clamd.sock
LocalSocketMode 660

The 660 setting will restrict opening the socket file to only root, the owner (e.g. clamav), and any user in the clamav group. Alternatively you may also set

LocalSocketGroup virusgroup

or maybe instead

LocalSocketGroup wheel

to instead allow users from the virusgroup or wheel groups to access that file and thus issue clamd commands.

This would effectively prevent untrusted user accounts from interacting with the clamd scanning service. It does not solve the problem of preventing users that may issue scans from shutting down the scanning service, but it should alleviate the most common concern.

We are open to future work to move control commands such as SHUTDOWN and STATS to a separate socket so that access can be more tightly controlled. But this will have ripple effects on all applications that use them today, including clamdtop.