Bug 259585 - security/clamav : Cannot start clamd if there is no /var/run/clamav directory
Summary: security/clamav : Cannot start clamd if there is no /var/run/clamav directory
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Yasuhiro Kimura
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-01 09:22 UTC by Thibault Payet
Modified: 2024-02-21 00:33 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (yasu)


Attachments
Populate /var/run from saved mtree (670 bytes, patch)
2022-08-27 21:10 UTC, Cy Schubert
no flags Details | Diff
The script for real now (670 bytes, application/x-shellscript)
2022-08-27 21:12 UTC, Cy Schubert
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thibault Payet 2021-11-01 09:22:59 UTC
Since the last update, clamd services will not start if there is no
/var/run/clamav directory.

By looking at the last update changelog:

* Stop checking in rc scripts if /var/run/clamav exists

This seems to be the issue.

Adding in clamav-clamd in the precmd()

if [ ! -d /var/run/clamav ]; then
		install \
			-d \
			-o clamav \
			-g clamav \
			-m 0770 \
			/var/run/clamav
	fi

Will allow the services to start, and user in the clamav group will be able to access the clamd socket.

Since clamav-freshclam and clamav-milter depends on clamav-clamd they don't need to check for the directory.
Comment 1 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-11-01 09:31:57 UTC
(In reply to Thibault Payet from comment #0)

/var/run/clamav should be created when the package is installed. Did you remove it manually?
Comment 2 Thibault Payet 2021-11-01 09:36:09 UTC
I have setup my /var/run as a tmpfs volume, so it is deleted every restart
Comment 3 Thibault Payet 2021-11-01 09:46:01 UTC
looking at man hier for /var/run it is:

system information files describing various info about system since it was booted

With that description, it means (to me) that content in /var/run could be totally wiped at start up.

But beware that the directory permission of /var/run/clamav should be 0750 and not 0755 else any user could access /var/run/clamav/clamd.sock

I did a typo in my "fix" it should be 0750 not 0770
Comment 4 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-11-01 10:04:51 UTC
(In reply to Thibault Payet from comment #2)

You should not do it. There is /etc/mtree/BSD.var.dist in all supported version of FreeBSD and it describes directory hierarchy under /var. So directories listed in it must always exist. and there are following lines in the file.

-------------------------------------------------------
    preserve
    ..
    run
        dhclient
        ..
        ppp             gname=network mode=0770
        ..
        wpa_supplicant
        ..
    ..
    rwho            gname=daemon mode=0775
-------------------------------------------------------

This means /var/run/dhclient, /var/run/ppp /var/run/wpa_supplicant should always exist. Using tmpfs for /var/run violates it. Moreover there are many ports that expects /var/run as no-volatile.
Comment 5 Thibault Payet 2021-11-01 10:58:11 UTC
Fair enough, then maybe add a note to the pkg-message to describe that clamav will not work if /var/run is a tmpfs since it is a change in previous behavior ?
Comment 6 commit-hook freebsd_committer freebsd_triage 2021-11-06 13:20:02 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=37e5d724fedb616b460f724d39365beced2331b7

commit 37e5d724fedb616b460f724d39365beced2331b7
Author:     Beñat Gonzalez Etxepare <bbtruk@users.sourceforge.net>
AuthorDate: 2021-11-06 12:38:27 +0000
Commit:     Yasuhiro Kimura <yasu@FreeBSD.org>
CommitDate: 2021-11-06 13:19:07 +0000

    x11-fm/doublecmd: Update to 1.0.1

    * Switch to use USE_GITHUB
    * Update WWW
    * Pet portlint and portclippy
    * Re-format Makefile with portfmt

    ChangeLog:      https://github.com/doublecmd/doublecmd/wiki/Changes-in-version-1.0.0
    PR:             259585

 x11-fm/doublecmd/Makefile                          | 161 +++++++++------------
 x11-fm/doublecmd/distinfo                          |  10 +-
 ...h-components_multithreadprocs_mtpcpu.pas (gone) |  22 ---
 x11-fm/doublecmd/files/patch-src_dmhelpmanager.pas |  24 +--
 .../patch-src_platform_udefaultplugins.pas (gone)  |  11 --
 .../patch-src_platform_unix_upipeserver.pas (gone) |  44 ------
 x11-fm/doublecmd/files/patch-src_uGlobsPaths.pas   |   2 +-
 x11-fm/doublecmd/pkg-descr                         |   2 +-
 8 files changed, 88 insertions(+), 188 deletions(-)
Comment 7 O. Hartmann 2022-01-25 08:31:00 UTC
I have the very same problem and for some reasons I won't discuss, because the reasons /var/run has to be on a volatile filesystem like tempfs is part of a "security concept" I've been forced to follow. The appliance reboots every 24 hours and so to cleance the /var/run tempfs amongs other folders/filesystems

As long the rc script of any service will check for the existence of its prerequisite folder, there is no issue so far of concern.

As far as I can think of there wouldn't be any security issue if the proposed solution would take place in the rc script of the port. We do so with a bunch of other services as well for years now and there has been no issue so far, even not with dhclient, wpa_supplicant or ppp as stated above.

Thanks in advance.
Comment 8 O. Hartmann 2022-08-27 06:17:04 UTC
See Bug 259699 - I provided a scheme of a solution, very simple and done by other ports, too.
With no doubt clamav is one of the most important, since solitary, AV software at hand and so it is common on many security aware installations. We work on a small appliance which utilizes NanoBSD as its embedded platform. /var/run among other folders is highly volatile since it is created in memory on boot time due to the limited write-cycle-lifetime of many NAND flash based memory options. 

Whenever this port receives updates, we have to re-patch our whole ports tree to fit the requirements for volatile /var/run and the solution could be so easy.
Comment 9 Cy Schubert freebsd_committer freebsd_triage 2022-08-27 21:10:48 UTC
Created attachment 236167 [details]
Populate /var/run from saved mtree

This will work for all ports. Copy it to /usr/local/etc/rc.d or /etc/rc.d (preferred), uncomment the stop target if you prefer to save the mtree manually.

I just wrote this today, adding it to my /etc/local/rc.d. As I already have a number of other site specific rc.d scripts, I added it there. To use your own rc.d directory, simply add it to rc.conf like this:

local_startup="/etc/local/rc.d /usr/local/etc/rc.d/slippy /usr/local/etc/rc.d ${KQ_KRB5_STARTUP}"	# startup script dirs.

There are many ways to solve this without changing every port in the ports tree that uses /var/run. If you want it to update your local /var/run mtree, emember to either uncomment the stop target in the script. Otherwise simply run the save target. I recommend running the save target for SSDs. Sure it's not a lot of writes but if you're paranoid about SSD writes running the save target after pkg upgrade or pkg install is your ticket.
Comment 10 Cy Schubert freebsd_committer freebsd_triage 2022-08-27 21:12:37 UTC
Created attachment 236168 [details]
The script for real now

Old brain. Forgot to attach the file.
Comment 11 Cy Schubert freebsd_committer freebsd_triage 2022-08-27 21:13:33 UTC
Ok that was bugilla's fault for not posting it quickly enough.
Comment 12 commit-hook freebsd_committer freebsd_triage 2022-09-05 13:20:58 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=27b9777c28b4e9474bdc500c28d04feec48fbb84

commit 27b9777c28b4e9474bdc500c28d04feec48fbb84
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2022-08-28 12:48:25 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2022-09-05 13:19:42 +0000

    libexec/rc: Add var_run rc script

    Users with a tmpfs /var/run will lose the directory tree state of
    /var/run at reboot. This rc script will optionally (by default)
    capture the state of the directory structure in /var/run prior to
    shutdown and recreate it at system boot.

    Alternatively a user can save the state of the /var/run directories
    manually using service var_run save and disable the autosaving of
    /var/run state using the var_run_autosave variable, for those
    paranoid SSD users.

    PR:                     259585, 259699
    Reported by:            freebsd@walstatt-de.de,
    Reviewed by:            philip, gbe (previous version)
    MFC after:              1 week
    Differential Revision:  https://reviews.freebsd.org/D36386

 etc/mtree/BSD.var.dist           |  2 ++
 libexec/rc/rc.conf               |  6 +++++
 libexec/rc/rc.d/Makefile         |  1 +
 libexec/rc/rc.d/var_run (new +x) | 47 ++++++++++++++++++++++++++++++++++++++++
 share/man/man5/rc.conf.5         | 28 ++++++++++++++++++++++++
 5 files changed, 84 insertions(+)
Comment 13 commit-hook freebsd_committer freebsd_triage 2022-09-12 00:41:31 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=3418c14040f240f0b7be9b2688c3682efcd5a7b2

commit 3418c14040f240f0b7be9b2688c3682efcd5a7b2
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2022-08-28 12:48:25 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2022-09-12 00:40:37 +0000

    libexec/rc: Add var_run rc script

    Users with a tmpfs /var/run will lose the directory tree state of
    /var/run at reboot. This rc script will optionally (by default)
    capture the state of the directory structure in /var/run prior to
    shutdown and recreate it at system boot.

    Alternatively a user can save the state of the /var/run directories
    manually using service var_run save and disable the autosaving of
    /var/run state using the var_run_autosave variable, for those
    paranoid SSD users.

    PR:                     259585, 259699
    Reported by:            freebsd@walstatt-de.de,
    Reviewed by:            philip, gbe (previous version)
    Differential Revision:  https://reviews.freebsd.org/D36386

    (cherry picked from commit 27b9777c28b4e9474bdc500c28d04feec48fbb84)

 etc/mtree/BSD.var.dist           |  2 ++
 libexec/rc/rc.conf               |  6 +++++
 libexec/rc/rc.d/Makefile         |  1 +
 libexec/rc/rc.d/var_run (new +x) | 47 ++++++++++++++++++++++++++++++++++++++++
 share/man/man5/rc.conf.5         | 28 ++++++++++++++++++++++++
 5 files changed, 84 insertions(+)
Comment 14 commit-hook freebsd_committer freebsd_triage 2022-09-12 00:44:34 UTC
A commit in branch stable/12 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=eb3e5718bfba6e39d5dd34238b789ffaed974fad

commit eb3e5718bfba6e39d5dd34238b789ffaed974fad
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2022-08-28 12:48:25 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2022-09-12 00:43:42 +0000

    libexec/rc: Add var_run rc script

    Users with a tmpfs /var/run will lose the directory tree state of
    /var/run at reboot. This rc script will optionally (by default)
    capture the state of the directory structure in /var/run prior to
    shutdown and recreate it at system boot.

    Alternatively a user can save the state of the /var/run directories
    manually using service var_run save and disable the autosaving of
    /var/run state using the var_run_autosave variable, for those
    paranoid SSD users.

    PR:                     259585, 259699
    Reported by:            freebsd@walstatt-de.de,
    Reviewed by:            philip, gbe (previous version)
    Differential Revision:  https://reviews.freebsd.org/D36386

    (cherry picked from commit 27b9777c28b4e9474bdc500c28d04feec48fbb84)

 etc/mtree/BSD.var.dist           |  2 ++
 libexec/rc/rc.conf               |  6 +++++
 libexec/rc/rc.d/Makefile         |  1 +
 libexec/rc/rc.d/var_run (new +x) | 47 ++++++++++++++++++++++++++++++++++++++++
 share/man/man5/rc.conf.5         | 28 ++++++++++++++++++++++++
 5 files changed, 84 insertions(+)
Comment 15 Cy Schubert freebsd_committer freebsd_triage 2022-09-12 00:49:14 UTC
You will need a sufficiently populated /var/run, one that contains all the directories needed by our system and the apps running on it. Set var_run_enable="YES" in rc.conf and reboot.
Comment 16 Matt Simerson 2024-02-21 00:33:32 UTC
I run clamav inside a jail and use a custom DB dir that persists across rebuilds of the clamav jail. Easy peasy. I modify clamd.conf and freshclam.conf to point at the correct path with rc.conf flags:

    clamav_clamd_enable="YES"
    clamav_clamd_flags="-c /data/etc/clamd.conf"
    clamav_freshclam_enable="YES"
    clamav_freshclam_flags="--config-file=/data/etc/freshclam.conf"

As of version 1.3.0, the rc.d scripts have the DB directory hard coded:

    # grep 'var/db' /usr/local/etc/rc.d/clamav-*
    /usr/local/etc/rc.d/clamav-    clamd:required_dirs=/var/db/clamav
    /usr/local/etc/rc.d/clamav-clamd:	if [ ! -f /var/db/clamav/main.cvd -a ! -f     /var/db/clamav/main.cld ];then
    /usr/local/etc/rc.d/clamav-clamd:		echo "Missing /var/db/clamav/*.cvd or *.cld files.  You must run freshclam first"
    /usr/local/etc/rc.d/clamav-freshclam:required_dirs=/var/db/clamav
    /usr/local/etc/rc.d/clamav-milter:required_dirs=/var/db/clamav

The sanity checks in the rc.d script are useful but they shouldn't stomp all over the ability to use the DatabaseDirectory config settings in clamd.conf and freshclam.conf. A straight forward solution would solve this with a rc.d like this:

    sysrc clamav_db_dir=/data/db

It would be good to also similarly make the run directory a config setting.