Re: clamonacc monitoring of Gitlab CI runner Docker containers

Andrew C Aitchison via clamav-users <[email protected]> Tue, 11 Nov 2025 20:05:05 +0000 (GMT)
Newsgroups gmane.comp.security.virus.clamav.user
Message-ID <[email protected]>
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 ...)

---

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 ?

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.

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

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 ?

-- 
Andrew C. Aitchison                      Kendal, UK
                    [email protected]
_______________________________________________

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