From nobody Sun Aug 28 11:01:07 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 4MFrGq01nJz4bLSw; Sun, 28 Aug 2022 11:01:23 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFrGn2qpsz40gJ; Sun, 28 Aug 2022 11:01:21 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 0355e33b; Sun, 28 Aug 2022 11:01:19 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 1026e1c6 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sun, 28 Aug 2022 11:01:19 +0000 (UTC) Date: Sun, 28 Aug 2022 13:01:07 +0200 From: Michael Gmelin To: Cy Schubert Cc: Michael Gmelin , 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 Message-ID: <20220828130107.1a76d54a.grembo@freebsd.org> In-Reply-To: <20220828102124.409EC26D@slippy.cwsent.com> References: <202208280842.27S8gDXn055868@nuc.oldach.net> <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org> <20220828102124.409EC26D@slippy.cwsent.com> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MFrGn2qpsz40gJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-2.10 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_SEVEN(0.00)[8]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_SOFTFAIL(0.00)[~all:c]; FREEFALL_USER(0.00)[grembo]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 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. 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. This is meant to inspire more discussions, I'm not trying to force anything in. ;) Cheers Michael -- Michael Gmelin