From nobody Tue Dec 23 15:37:13 2025 X-Original-To: freebsd-hackers@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 4dbJzr10Jsz6LcHH for ; Tue, 23 Dec 2025 15:37:44 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from irmo.kmail.bg (mx.kmail.bg [82.118.243.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbJzq572Gz3F2n for ; Tue, 23 Dec 2025 15:37:43 +0000 (UTC) (envelope-from roam@ringlet.net) Authentication-Results: mx1.freebsd.org; none Received: from straylight.m.ringlet.net (unknown [94.26.75.156]) by irmo.kmail.bg (Postfix) with ESMTPSA id 90D4D40138 for ; Tue, 23 Dec 2025 17:37:13 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 128dcde by straylight.m.ringlet.net (DragonFly Mail Agent v0.14 on straylight); Tue, 23 Dec 2025 17:37:13 +0200 Date: Tue, 23 Dec 2025 17:37:13 +0200 From: Peter Pentchev To: Andrea Cocito Cc: freebsd-hackers@freebsd.org Subject: Re: Retrieving the kid/jailname of connected peer for a unix socket Message-ID: Mail-Followup-To: Andrea Cocito , freebsd-hackers@freebsd.org References: <7878EFBC-2BCF-42ED-9BFC-D96DC0DDC23A@cocito.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="77oyHrR5/ykVUJHX" Content-Disposition: inline In-Reply-To: <7878EFBC-2BCF-42ED-9BFC-D96DC0DDC23A@cocito.eu> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:31083, ipnet:82.118.243.0/24, country:BG] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbJzq572Gz3F2n --77oyHrR5/ykVUJHX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 23, 2025 at 01:54:31PM +0100, Andrea Cocito wrote: > Hello hackers, >=20 > I am working on a project in which I run a =E2=80=9Cweb server=E2=80=9D b= ound to a unix socket; > the socket lives in a directory that is re-mounted as a read only nulls in > various jails, so processes in each jail can make requests to this =E2=80= =9Cserver=E2=80=9D. >=20 > I need the server to be able to know from which jail the request comes, a= nd > this is needed as an authentication method. >=20 > So far the best I could do is a three-step approach: > 1. I retrieve the pid of the process connected to the other side of > the socket: getsockopt(fd, SOL_LOCAL, LOCAL_PEERCRED,=E2=80=A6) > 2. I map that pid to a jid: int mib[4] =3D { CTL_KERN, KERN_PROC, KERN_PR= OC_PID, > static_cast(pid) }; sysctl(mib, 4, &kp, &len, nullptr, 0) > 3. I map the kid to jail name with jail_getname() >=20 > As LOCAL_PEERCRED returns the peers=E2=80=99 credentials "as they were ca= ptured when > the socket connection was established=E2=80=9D and there could be a small= delay before > we accept() there is an unlikely but formally possible TOC-TOU issue that > potentially could be exploited as follows: > a. A process with pid P in a jail starts and attempts a connect() > b. In the meanwhile a connect-bomb or other =E2=80=9Coverloading=E2=80=9D= technique slows down the server > c. Process P passes the fd to process Q and exit()s > d. If when we accept() another process (potentially in another jail) has = got > pid P... we get the wrong information If you are afraid that some process will deliberately try to circumvent your access control by passing the fd, then I don't think you can really guard against that. Assume that your check is instantaneous; in that case, what w= ould prevent a process to connect(), wait until you perform the access control c= heck, then pass the fd to another process that will issue requests? Even if your check is not instantaneous (which it cannot possibly be, as you've found), still a rogue process can e.g. connect(), sleep(1), and then pass the fd. What exactly is the threat scenario you are trying to mitigate? G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --77oyHrR5/ykVUJHX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmlKtyQACgkQZR7vsCUn 3xN2/g//dU53N62HPQyIHqo0allZ0Gp5uJ0eK7HKq+GMf/lItX4PCbKHGBKmCMc+ J5v01OYgVUGiWsHtY0JF0vAKMZKoBTO/Q8iA686yFQSepMh+CAQVeGMt9OIWadIk sei6I1Psxu40CqxHEah/n2p5OvKsMnxFYd+Txz3GeB1QfON6OBIBhiutborAW/Zu O2SeMHGUpkgOfgADLW2B+arnSlyP1kattNXz8n70h1sv267XOXw5WQ52NLtP82QQ tn/hjaJbK3lKNFoiEVp9Gm7k7A/3FDlSt31ePSpFYgqIJiOWmYV3dAZYPuGnB56U CHYEyQHUVrevTCsSNEFhACfKqcti/Fxq124hw2Vv6SccJ31E4fwSbdaiMd9Ya0xP gBEEkNIQp/GVdVr6Pbh8rzvmf4Sq7sLXAOjmbOAMqfjj43jtnDyxG6/y/Ov1jqhB z+NwsgKEpZO7948f3ZujeEGiOGUkZHivzlwQa39X25Ea2RLE86KIG9iVD3Akgmqx r9yoRNrAUj4aHsCYUka8FHI9/GFyVcQb5xplZ5jfv0PBsMbSYGCIDhAwjcjwE7ZQ XbSZmlEwdKfJzANndRAwOy1PitDVHKRuHneY9SnZPBK6HAneRaUXm7Sg6zBFgXsA anVlQRD7ZEIAgq5dLmKeUtdKENqQQwF6V5m8q269R/9SNqHhKMU= =Jnt8 -----END PGP SIGNATURE----- --77oyHrR5/ykVUJHX--