Hey Ged,

Thanks for the reply and info on the regex stuff.

Understand that those hidden dirs are places malicious files may target.

To give you the bigger picture on the setup.

This is for a system to provide web browsing over VDI to users in a secure 
environment (i.e. no internet).

Each user has a docker container running a web browser. The home directorie are 
only used for the browser & live on a dedicated NFS server.

Although users could download files to various places in the container, only 
the Downloads folder of the home directory is exposed via the VDI solution to 
the user to pull files out of. I.e. only from Downloads can they retrieve files 
and download to their actual machine in the secure zone. So my thoughts were it 
may be a small risk & more performant to exclude the other dirs.

Interested to know your thoughts.


Nick


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, 4 February 2021 13:14, G.W. Haywood via clamav-users 
<clamav-users@lists.clamav.net> wrote:

> Hi there,
>
> On Thu, 4 Feb 2021, Nick via clamav-users wrote:
>
> > ... Ideally I want to only scan:
> > /user-home-folders/*/Downloads
>
> Your users won't save downloaded files anywhere else?
>
> > ... could I do something like the below?
> > OnAccessIncludePath to /user-home-folders/
> > ExcludePath /.local/
> > ExcludePath /.cache/
> > ExcludePath/.config/
>
> Unlike OnAccessExcludePath, the ExcludePath directivedoes take a
> regex so you could for example use
>
> ExcludePath ./\..
>
> which means anything which has a dot immediately after a slash. This
> is untested, but I have reasonable confidence in the regex matching
> used by clamd. Occasionally I've played around with it when testing
> other suggestions on the list.
>
> > In testing this I still see clamonacc tell me it's performing
> > scanning on files created in .cache but will the engine itself
> > ignore them due to the Excludes?
>
> I've never used on-access scanning so my knowledge of its alleged
> behaviour is only from reading. I understand that the clamonacc
> daemon is a client of the clamd daemon, so I would say that AFAICT the
> clamd daemon respects its configuration so the answer is 'yes', but I
> would also urge you to find out by experiment. That's what I usually
> do if I'm unsure of any behaviour - particularly with things like
> regexes, which might be supplied by your local libraries, and not by
> the upstream sources that you've just built. The main toothache in
> the process is waiting for the daemon to reload its configuration
> after each configuration change.
>
> > Is there a better way of accomplishing this?
>
> Personally I'm not convinced that you should be doing it at all. If I
> were a malicious actor and I wanted to hide things in your filesystem,
> then the directories you're excluding are amongst the obvious targets
> for some place where lots of garbage gets written and then ignored by
> the people using the box.
>
> On the other hand you probably haven't yet attempted to calculate the
> probability that what you're doing will achieve the desired results.
>
> What are the desired results?
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 73,
> Ged.
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml



_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Reply via email to