From nobody Tue Dec 23 18:05:55 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 4dbNGz5fr5z6K6Hf for ; Tue, 23 Dec 2025 18:06:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbNGz3nB7z3dTW for ; Tue, 23 Dec 2025 18:06:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-45066bee74aso1577535b6e.2 for ; Tue, 23 Dec 2025 10:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1766513157; x=1767117957; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=X57PsUsETIXtN4zoJ44B6ymB5TZI558iEXjgfHK6Yio=; b=iPFFojGxVVGMpHJ+09P4GVXt/PyKCwcQzV3zZS/e2wuuVLNIMX5+eYGzgsA2sneU1a z5WDfM/OJ2onVhJu0ZJcbxH9n2DMXVdhXJ/fEhfMrIWkThRLcCB+NAnZBr30Idhq5Xkj cgakcu3BKYD5II0Xr4kBzVdErmnHDhXfaAKonUl0o3DFweF/AVYxSJi/5VigbGJvpsxd h+BdIvH4o7yMJwze0sWGSrvZoKncKTVXac5ur446Di1M3n38nlBnKL17rABo5ZtbcIrj L3cV1qfb4I4EUyImaA6SqaLy2Veqxc7rKrQG/lu2XnuZvVR6qnMQzkjUvPcsjCMqGS1D PrrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766513157; x=1767117957; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X57PsUsETIXtN4zoJ44B6ymB5TZI558iEXjgfHK6Yio=; b=KZpB0OUCmQAQS738RemR+ytkHx+RPshuw8sona4YhSNF6sZrUXwMiQOF9vy+n3YsgD opQeKMKRq24GSSzdpuBt9wBMQ2dnPf9hHJ5H8lA8kIqEhDEP2I4t+VWyEtLONndN0spe EMjn6PXQn4jlfIuXaLnfks76ity4Z0Fk2/7yF0RTOR+p7GBT5LtPkgpPJL5NpiMXNQlU qPCZPhVZNz579uLDXYNzXEC/Mw2aOCsap1Rqb3O6jiDmR3ADtSDsuGm05vLfSVagRA+h x+TcjyDBf3fJDtEY829O1OOFi9mR3zkB/nOWpjWXNP3+ajsEyGRXGFf40OJ1DWZN/Xro 0Zcw== X-Gm-Message-State: AOJu0YwpuA9Ig+oIbMRzB/wiEZ9P4VnxrFrdS615aMVtwV8LjsOsAzEe GHNv2hpo9wmL/SsBsMj5TdfKzfvVYv1oE3g5AOlbdl5kfHKCdfuM+wxHywsXDYcOb6zHvZBowl9 jSqSl8Wc= X-Gm-Gg: AY/fxX6tLtYNAw7SbJeeCNpkkjn3nNyrYZGig+57cqFNOB1QRjls5D4h8JDr3zOljUe oQ9+JJZ1i9hQ4PvpEVuctKrpzs2dizIZKbXqUBCxlBJfnouJMm/Yy7W9wfVeIFOKL/ZZy58hJx0 JzjA6vNMHcHe3D6Fe7ZxO+eNLbrWmvAL7FP5xHPDJs2FAz1Ee+pLf5+WHg/EqwInSbKB7+ldHtd VcoSR/i52S2JagDeqcWGo4ORyqWNHxiwnx1Jo8jV6hMqJe77abVtnwYql1yGhozXNd3O4PC7Fe1 gznYvrNdnD6g4TtxpYwcBqIVXtKAbGiv8ui7wknoNtyDdZ5yM/kRn01/KZlEXNsf/KWy4LGiWKj HHIjaAEYwc9J47J/Zl37hGpC8kXem3nPHL7tzXKssdsHSznICDPVotZLuA/RZq5w7qV9y X-Google-Smtp-Source: AGHT+IFN7LgcV4y/oN85cBiPVA17ptUfqqNQj7Q3dmGgHqyY0pDxAk1puWPKXT7OtqMVTKHXd9M9Ag== X-Received: by 2002:a05:6808:4f5f:b0:450:c9ad:491b with SMTP id 5614622812f47-457b20f32abmr6587269b6e.8.1766513156716; Tue, 23 Dec 2025 10:05:56 -0800 (PST) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 5614622812f47-457b3edb516sm6658601b6e.15.2025.12.23.10.05.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Dec 2025 10:05:56 -0800 (PST) Date: Tue, 23 Dec 2025 18:05:55 +0000 From: Shawn Webb To: Andrea Cocito Cc: freebsd-hackers@freebsd.org Subject: Re: Retrieving the kid/jailname of connected peer for a unix socket Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.3-STABLE-HBSD FreeBSD 14.3-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc 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-sha256; protocol="application/pgp-signature"; boundary="v2k27yduzy36jugs" 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbNGz3nB7z3dTW --v2k27yduzy36jugs Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Retrieving the kid/jailname of connected peer for a unix socket MIME-Version: 1.0 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 a= s a read only nulls in various jails, so processes in each jail can make re= quests 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 s= ocket: 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 possi= ble 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 >=20 > As a mitigation I am currently resolving fd->credentials->jid->name as so= on as possible server-side and obviously using randomized pids, but there i= s still a formal delay in accept() and I understand I am violating the gold= en rule =E2=80=9Cdo not use a pid to grant permissions/authenticate=E2=80= =9D. I also tried to investigate other safety options (like check that pid = actually started before the connection took place) but it seems that nothin= g from the kernel exposes the =E2=80=9Ctimestamp when connect() was called= =E2=80=9D, so I always have the connect()-to-accept() windows of risk. >=20 > So the question is: am I missing some simpler or safer way to get the "ja= il id of the process which connected to the other side of this unix socket"= , besides embarking into =E2=80=9Cset LOCAL_CREDS_PERSISTENT and check LOCA= L_CREDS on received traffic=E2=80=9D, which would be quite complex to plumb= into Crow-http? >=20 > Thank you for any comment/hint and have an hacking Christmas.=20 >=20 > A. >=20 > PS: I do not consider any TOCTOU between steps 2 and 3 above as I conside= r the parent machine =E2=80=9Csafe=E2=80=9D and give for sure that no-one w= ill create a jail with a different name and the same jid inbetween, The first thought that comes to my mind is the MAC framework. I don't know of anything off-hand that would work for you. If you're not opposed to enforcing the security boundary in kernel code, the MAC framework might provide a nice interface for you. When an attempt is made to connect to the UNIX socket, your MAC module could check the appropriate credentials structure and make the determination of whether the connection should succeed based on the value of the cr_prison field in the credential structure. I'm unsure of whether there are any userland APIs for determining a given connection's (or connection attempt's) originating jail. Hopefully that helps. I'd be curious to know what solution you do end up adopting, regardless of whether MAC is involved. So please do keep this thread updated. :-) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --v2k27yduzy36jugs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmlK2fUACgkQ/y5nonf4 4frkJA//ZAI9rrK7EF/9dMse2u8tyBGO2iF0tBklzCIFXlMJRPk0+2y1YEeB5IDL xw8RIK29UDN4BN6nNriIKq4SwOe3tDYxbj//YJi2KWVqOkjFmJpfANWTRNyYZqvJ oK6twxD2/GlGZmaN23Dj0gv4kBQ4qHD94P37UPD5ZecTI7rZ/8C08/jPviiOhQab 4YPRUc7dj8zhX/Xb60OVXOSXbgwSkJQVhrqiyaZ57vCKxyntVDZYvjvGP4v6Yo9r /BC0dPaG9yZXz2n4q5Wvwgw4uLRp+F6VE11SV8Tuyx91QJv3lpRkHE5TpP35/htA yLnjl3rPowdOoZyx65I3keda1iWPvD5EIYHgDcobAtkEA4YELXvy9uCtJBezQVVG Y+J/HI0TibM/wCNXLHwm6le8DaU/U2e+yTwwvxnCaUQOP639/X46EjlrzcrDwL3N X5gjPsyvgcOiWAp+yjUH8fYmo6DjBWDGJ7OKcfDw9LK7Jv8eZhSFtytxDmy54V7q QHN+0RtmVBw2345VXgyxFovvYr8zFHwz7SYZshApPMIFwfbGBVi8hOVi9/TPsDJW eJJUeNHNgzc12kMBg99aZhCKK5jGu3GVMwfRAjJmRwojzSmSbKxHuiRVtsqV1itw 6MfmtwYBs7D0oyoBnwxccxASl1sA6nyHeKnhGtUCGAhN4YI1DiU= =a1f5 -----END PGP SIGNATURE----- --v2k27yduzy36jugs--