From nobody Sun Aug 28 13:11:20 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MFv8r71qdz4ZZTc; Sun, 28 Aug 2022 13:11:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFv8q6pyHz47N3; Sun, 28 Aug 2022 13:11:23 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id SHnyoRnxvS8WrSI4RoPzF5; Sun, 28 Aug 2022 13:11:23 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id SI4PorK7juJwwSI4PoTmPw; Sun, 28 Aug 2022 13:11:23 +0000 X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=630b697b a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=gRS1eiuiAAAA:8 a=EkcXrb_YAAAA:8 a=haJdyl2PuIvToo3mPV8A:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=udpbrAo2yJH2O6eCpvBn:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id CD16DC71; Sun, 28 Aug 2022 06:11:20 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id C3781317; Sun, 28 Aug 2022 06:11:20 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Michael Gmelin cc: Cy Schubert , freebsd@oldach.net, otis@freebsd.org, freebsd@walstatt-de.de, freebsd-current@freebsd.org, freebsd-ports@freebsd.org, yasu@freebsd.org Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by design In-reply-to: <20220828130107.1a76d54a.grembo@freebsd.org> References: <202208280842.27S8gDXn055868@nuc.oldach.net> <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org> <20220828102124.409EC26D@slippy.cwsent.com> <20220828130107.1a76d54a.grembo@freebsd.org> Comments: In-reply-to Michael Gmelin message dated "Sun, 28 Aug 2022 13:01:07 +0200." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Aug 2022 06:11:20 -0700 Message-Id: <20220828131120.C3781317@slippy.cwsent.com> X-CMAE-Envelope: MS4xfKkQmmCNPaOcN6yeOjUAajwkZ5rcAKXFGIO12O0q/Mays8QFxkJfMa6plv2ucTS27u4Zmw+zJBMXxiGcLgDW+odNRH/KoRhFcVRJSPn8/15+bR0LOtga EMrvQdPn1Ene7NnUdrMZ1vha8gh0msmtj4zB7+ayDSUEWx95Uc7WSmoJ3TnU30a5cTPNEOCeW5tEK8Lx1ol8zxE+1AyBuOvf921m6jL/nMzFEDCSTZk6ExAz f7zemrJpmFkfrClIoNmjN1uqg3pHTiRppPfPdMBlfl9i/WXdFW7mHXZaIIhRqbAphW7eyJlKbZN59jVbuRcMUzZR7ifzHT2OI94+ElgmqH6IzMnZWaTDF70e ZvyAYPrIodxUB/bBGNmpW3JyJhWprRa5cHLYy/6+vZKsV2fH+2Y= X-Rspamd-Queue-Id: 4MFv8q6pyHz47N3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N In message <20220828130107.1a76d54a.grembo@freebsd.org>, Michael Gmelin writes: > > > > On Sun, 28 Aug 2022 03:21:24 -0700 > Cy Schubert 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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0