Re: clamonacc monitoring of Gitlab CI runner Docker containers

On 11/11/2025 20:05, Andrew C Aitchison via clamav-users wrote:
>
> On Mon, 10 Nov 2025, Tom Jordan via clamav-users wrote:
>> ClamAV newbie here. I'm looking into setting up a Gitlab CI runner on 
>> an Ubuntu 24.04 host VM. The Gitlab CI runner configuration is 
>> nothing unusual, it will be sent jobs by the Gitlab CI server and run 
>> the CI jobs in Docker containers spun up for each job and destroyed 
>> after the job has completed. However, in our environment security 
>> (against malware, viruses from the internet) of the running 
>> containers is a big concern. We plan to do image scanning of the 
>> Docker images for vulnerabilities, and regular rebuilding (per 
>> pipeline) but we also want protection of the containers when they are 
>> running.
>>
>> My question: is it possible to configure a clamonacc on the CI VM 
>> host to perform on-demand monitoring of the containers filesystems? 
>> This would be preferable to clamonacc running inside each container. 
>> It feels like it is a reasonable use-case and that it should be 
>> possible, but it is not clear to me from the ClamAV online 
>> documentation or from general internet searches on the problem, 
>> whether it is possible/how easy it would be to set up.
>> Any help/advice appreciated.
>
> https://news.ycombinator.com/item?id=35323730
>    suggests that what you want was not possible at the time (2023)
>    With fanotify, you would need to manage the mount points for which
>    notifications need to be received. This works semi-OK for a static
>    use case, but not for dynamically-created mounts and, worse, mount
>    namespaces.  In other words, fanotify is not suitable at all,
>    without a lot of glue, for monitoring events happening in
>    containers. And, for example, clamonacc (on-access file checking for
>    ClamAV) does not work with removable storage, temporary network
>    mounts, and containers for this very reason.
> (There is follow-up saying that the original article that
> this is a comment upon, may be out of date ...)
>
Ok, that is helpful. I've some familiarity with inotify but haven't come 
across fanotify until now and am not familiar with it yet. I don't know 
what clamonacc uses under the hood, I assumed it was something like 
inotify, which as noted below definitely can reach from the host VM into 
the running container's file system.
> ---
>
> This is the first time I have come across this idea;
> I am thinking aloud.
>
> If clam running on the host can see the file access events within
>   the container, doesn't that violate the privacy of the container ?
>
Arguably, yes. However, you can already violate the privacy of the 
container (access its files from the host) using inotify and many other 
even more general tools ('cp' etc) and it seems a reasonable use case 
for doing it with Clam in this case (security trumps privacy)
> To me that means you would either have to use a feature of the
> container or get something inside the container to pass the file
> system events to the scanner.
>
> You may be able to do the second by running clamonacc and configuring
> it to use a networked scan daemon running it on the host.
>
That might be worth looking at. I'm currently running both clamd and 
clanonacc locally on the host, however I did see that there are some 
alternative configuration options (port number and host address) in 
clamd.conf suggesting a networked configuration is possible, though I 
haven't tried it. It could be worthwhile if it is only the scanning 
daemon which is memory hungry, which I expect it probably is.

Although if clamonacc is configured to instantly move the offending file 
as per

sudo clamonacc --move=<quarantine_directory>

would that still work if the clamonacc is running on the container, 
quarantine_directory is a directory on the container and the clamd scan 
daemon is running on the host? In other words, does the clamonaccdo the 
actual file moving or is it the clamd scan daemon which tries to do it. 
If the latter, that would possible also fail in trying to do it from the 
host VM side, wouldn't it?

> ---
> Your second email suggests that inotify *can* see inside the container.
> There is at least one other mechanism - fanotify - by which the Linux 
> kernel can alert interested processes of file system changes.
> clamonacc contains code for both inotify or fanotify, but I don't
> know where each is used.
>
inotify (inotifywatcher) definitely can see inside the container (with 
sudo privilege, IIRC)
> As always, permissions will always need to be
> correct for things to work and be safe.
>
> ---
>
> Since the container filesystem is thrown away when the job finishes.
> I am not sure what you hope to achieve. Would monitoring the input to
> and output from the container have the same effect ? 
It comes about from company policy, which is dictated by CyberEssentials 
compliance (more specifically our interpretation of it). The argument is 
that a container running a CI job may pull something dodgy from the 
internet and could potentially, before the job finishes, copy it onto 
our network, e.g., via a connection to networked file-store.  I'm not 
sure how otherwise we could police everything that comes out of every 
container, to make sure it is safe, other than catch it when it comes 
into the container and do something with it like move it into quarantine.
_______________________________________________

Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation

https://docs.clamav.net/#mailing-lists-and-chat