Date: Tue, 23 Dec 2025 18:05:55 +0000 From: Shawn Webb <shawn.webb@hardenedbsd.org> 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: <zoyfg5o4yxouok6i7c6i4pqqyxn6ytukfgxssd64mrmqgcdtvk@cnt7vgwgeddv> 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
>
> As a mitigation I am currently resolving fd->credentials->jid->name as soon as possible server-side and obviously using randomized pids, but there is still a formal delay in accept() and I understand I am violating the golden rule “do not use a pid to grant permissions/authenticate”. I also tried to investigate other safety options (like check that pid actually started before the connection took place) but it seems that nothing from the kernel exposes the “timestamp when connect() was called”, so I always have the connect()-to-accept() windows of risk.
>
> So the question is: am I missing some simpler or safer way to get the "jail id of the process which connected to the other side of this unix socket", besides embarking into “set LOCAL_CREDS_PERSISTENT and check LOCAL_CREDS on received traffic”, which would be quite complex to plumb into Crow-http?
>
> Thank you for any comment/hint and have an hacking Christmas.
>
> A.
>
> PS: I do not consider any TOCTOU between steps 2 and 3 above as I consider the parent machine “safe” and give for sure that no-one will 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,
--
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/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
[-- Attachment #2 --]
-----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-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?zoyfg5o4yxouok6i7c6i4pqqyxn6ytukfgxssd64mrmqgcdtvk>