Date: Tue, 23 Dec 2025 17:37:13 +0200 From: Peter Pentchev <roam@ringlet.net> To: Andrea Cocito <andrea@cocito.eu> Cc: freebsd-hackers@freebsd.org Subject: Re: Retrieving the kid/jailname of connected peer for a unix socket Message-ID: <aUq3Kae4qd8_X-bM@straylight.m.ringlet.net> In-Reply-To: <7878EFBC-2BCF-42ED-9BFC-D96DC0DDC23A@cocito.eu> References: <7878EFBC-2BCF-42ED-9BFC-D96DC0DDC23A@cocito.eu>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Tue, Dec 23, 2025 at 01:54:31PM +0100, Andrea Cocito wrote:
> Hello hackers,
>
> I am working on a project in which I run a “web server” bound 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 “server”.
>
> I need the server to be able to know from which jail the request comes, and
> this is needed as an authentication method.
>
> 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,…)
> 2. I map that pid to a jid: int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PID,
> static_cast<int>(pid) }; sysctl(mib, 4, &kp, &len, nullptr, 0)
> 3. I map the kid to jail name with jail_getname()
>
> As LOCAL_PEERCRED returns the peers’ credentials "as they were captured when
> the socket connection was established” 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 “overloading” 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 would
prevent a process to connect(), wait until you perform the access control check,
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
--
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
[-- Attachment #2 --]
-----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-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aUq3Kae4qd8_X-bM>