Re: security/clamav: /var/run on TMPFS renders the port broken by design

In message <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>, 
FreeBSD Us
er writes:
> Am Sun, 28 Aug 2022 06:11:20 -0700
> Cy Schubert <Cy.Schubert@cschubert.com> schrieb:
>
> > In message <20220828130107.1a76d54a.grembo@freebsd.org>, Michael Gmelin 
> > writes:
> > > 
> > >
> > >
> > > On Sun, 28 Aug 2022 03:21:24 -0700
> > > Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> > >  
> > > > In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>,
> > > > Michael Gmelin w
> > > > rites:  
> > > > > 
> > > > >
> > > > >    
> > > > > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> > > > > >=20
> > > > > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > > > > (CEST):    
> > > > > >> As stated before in this thread, replacing /var/run with tmpfs
> > > > > >> is not a supported configuration.    
> > > > > >=20
> > > > > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > > > > creates a t=    
> > > > > mpfs backed /var, populates it through mtree, and makes a proper
> > > > > /var/run av= ailable.    
> > > > > >=20
> > > > > > However it doesn't (yet) create /var/run/clamav of course.
> > > > > >=20
> > > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > > > > walks thro=    
> > > > > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > > > > found as need= ed. All that the security/clamav port would need to
> > > > > do then is to drop an ap= propriate small mtree file as
> > > > > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > > > > the same logic as dropping service scripts as /usr/local/=
> > > > > etc/rc.d/clamav-*.
> > > > >
> > > > > =46rom a user's perspective, it would be preferable to have this
> > > > > happen at s= ervice start though, as (unlike in the setup
> > > > > described) reboots don't happen= that frequently, but files in
> > > > > /var/run might get deleted manually. Maybe so= me rc framework
> > > > > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > > > > which, if set, is applied in the default start_precmd. Besides
> > > > > being mo= re resilient, this would also have the advantage that all
> > > > > required file syst= ems should be available at that point and the
> > > > > separation between system and p = orts would be more clear. Another
> > > > > advantage would be that directories are on= ly created for services
> > > > > that are actually enabled/started.    
> > > > 
> > > > Unfortunately this requires all ports to include an mtree file.
> > > > Relying on port maintainers who are human to ensure that these files
> > > > are created and updated when ports are created and maintained will
> > > > result in more human error. I've learned over my long career to rely
> > > > more on automation than human beings. Automation [should] never fail
> > > > and when it does it does temporarily until the bug is found and
> > > > fixed. Human beings inconsistently fail.
> > > > 
> > > > If it were an auto-discovery script that created an mtree file as
> > > > part of the packaging process, it would be another matter. But this
> > > > optional solution path should be discussed on ports@, not here.
> > > > 
> > > >   
> > >
> > > I don't have much skin in the game, but I created a little proof of
> > > concept to allow further discussion (which is not ports-specific, as it
> > > works for all service scripts):
> > >
> > > https://reviews.freebsd.org/D36385  
> > 
> > I've been toying with the idea for a few months but was never bothered to 
> > create a review or even a script for that matter.
> > 
> > >
> > > This basically allows both system admins and port maintainers to
> > > create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
> > > always relative to the service script called) which are automatically
> > > applied on service start. It's non-intrusive and doesn't require any
> > > sweeping changes to existing ports/services.  
> > 
> > Understood that this is a manual process.
> > 
> > >
> > > In this specific case, the requester could create
> > > /usr/local/etc/mtree/clamav-clamd with the required content (or
> > > persuade the port maintainer to include that file).
> > >
> > > You could of course add some construct to the ports framework that
> > > picks up certain directories from the package list automatically and
> > > places them into an mtree file as part of the build or installation
> > > process. But that would be an additional feature on top of this change.  
> > 
> > Someone could. Personally, I think that's a lot of work compared to simply 
> > saving the state of /var/run at shutdown and restoring it at boot. I can't 
> > speak for the ports management though.
> > 
> > >
> > > This is meant to inspire more discussions, I'm not trying to force
> > > anything in. ;)  
> > 
> > Agreed.
> > 
> > I cobbled something up yesterday that saves the directory tree state of 
> > /var/run prior to shutdown (or manually) and restores it at boot.
> > 
> > https://reviews.freebsd.org/D36386
> > 
> > People can try it out if they want. If there's enough interest I'd be 
> > willing to commit it.
> > 
> > We have a few options on the table and probably more. The ports 
> > infrastructure option is probably the most work. Adding functionality to 
> > all the ports that use /var/run is also a lot of work and if relying on 
> > individual porters, will likely take some time and be varied in 
> > implementation and robustness.
> > 
> > 
>
> I'd like to add a sidenote here, if one may please.
>
> Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var res
> ide on a memory
> disk and the way NanoBSD handles /var, contradicts some claims that is is 'un
> supported' to put
> /var on a volatile memory infrastructure.

There is no argument that /var/run on tmpfs should not be done. IIRC RHEL 
puts /tmp and /var/run on tmpfs. And, when I worked with Solaris and Tru64, 
both put /tmp on tmpfs.

>
> On the other hand, there are only few ports which create subfolders to, i.e.,
>  /var/run not
> congruent what the specific metree sketch implies, the port security/clamav i
> s one of those
> few.

If /var/run is tmpfs when the system is built the script I posted would 
handle this. However, after the tact, and remove the old /var/run instead 
of having the tmpfs mounted on top of a fully populated /var/run that 
should probably be removed. But we can leave that as an exercise for the SA 
to figure out.

>
> The question that bothers me most and this is just from the pratical point of
>  view as stated
> initially and from a second view, just out of curiosity:
>
> what (fatal?) implications does it have to create some folders by port's rc-s
> cript in /var/run
> or whatever folder is needed to be on a volatile memory device for FreeBSD ba
> se system's mtree
> infrastructure?

You need to ask port maintainers that. But remember, shotgun approaches to 
problems simply create technical debt that has to be paid with interest. 
And, it's always the developer who pays.

It's better to consider a holistic solution rather than pick away at it.

Try my rc script. Simply enable it and change your /var/run to tmpfs. Then 
reboot. If you want to dispose of any cruft on disk you can reboot into 
single user and clean it up at a later date.

One final word: We should consider /tmp and /var/run as tmpfs as default, 
just as RHEL, Solaris and back in the day Tru64. (Though I recall DG/UX, 
HP-UX and NCR AT&T SysVR4 never used tmpfs.) On the flip side, embedded 
systems with limited RAM may be the exception but that can be mitigated 
with a size option (not used by Solaris but used by Tru64).

Try the script. ;)


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0