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
