31.google.com with SMTP id 5b1f17b1804b1-47796a837c7so35402475e9.0 for ; Tue, 23 Dec 2025 08:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cocito-eu.20230601.gappssmtp.com; s=20230601; t=1766505779; x=1767110579; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=AenosEjOe8vTgVc0vRCjALnYRoT7y1Tt7NDbhEN6LzU=; b=Plm//0oDPdkQggKlzkrX+agNZgrtrV/ZaEcSLfCC8mXr0UAHj+rkdq64DgxGQw03c3 qZiZaO9fZC+YgC/O9zMN+NxYxtw3PmilrqV98S/kOR8E+a3hoT5a6ODFG+PzkYuqZM7P 6J/fu3+0/4Hx9HWFLU9+L/k6PHTCVTp5kylRYcR6T4QEKQ6Eg4WPf+EobYgAGwL8tEE9 n+G5q0OvxizV8OKcD5yRlxZhpFf+RxI9vaNVc792M+3zgnVdWUQJZUPumz82ATl2rLMe cxqXFGV6GsaOt4P84Kie12C5HEpd56NZy/K4Ak/DaMoauzBEupkvSxj5xHEaHXNt/u3L 3jTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766505779; x=1767110579; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AenosEjOe8vTgVc0vRCjALnYRoT7y1Tt7NDbhEN6LzU=; b=gtclZcP30Xb75P68zUrTEGk8g8dXZpq2G57cakKD4Luztsin9rjaJ2/h7d/b6NtfmK 9TdS9AKghHB0GRBPVDfaOt12Ch2goHdxEH3NzHTeDgOIExa2Nq/GVRnegN2Pxd7SRTQu BP5eNMRiEKn5g9iystNABRFdxsEL+LEEWLwt8SZDEc96tU7keumQZmeG1SbAbCz75TjV E8aa2FSTfck4h+IMMvUU0DbT5M5lB7YOT6iy7Xel+TBumAcekp1kzqY97lYHaZiMfkSp F7JahfgfJ+z+Wrfq+icXTyNZ9cCVQOt37SDOooKJfSqs/QftUVXzUSu3mzR0fuwAGREB 7JTQ== X-Gm-Message-State: AOJu0Yxoi0N7mvY8UvwTg7XsZvSSEkM/IsAhMr78Ax9HhqM73e8cY90B Mf+5G/kKe6NCDhd/sWv5n3NeJ7E5e/oev89sJphCTU30f/Cox9edVLf1N1mbDA2Bbks= X-Gm-Gg: AY/fxX6b52yfoLdF0cYI8x4IiztB7N8ckAy7xjWHdiRf7+VTxSRgyCLe/uWZivqQzKl SnfmbuewK/lhnY+itIV6tV5+PLOVijSomUpMgPBPM4ltk5qM5yEUW6M4FFlT0Jf51EMx8zufG6m Lk+rZM20BJK1tc0TdMgf+HWB+ejDvntnRu8/JuxtVTglJYVNwIPKV2GY6BwC92hc6+4qKQOqN6u P1HOQwUK1lRs1n6zNVgwsci+honuMV+c2jPI7JAKYb6w4F/3TgHB06t1CRHdnoqIG1+MMbaele0 N81QUXMGhyf/txU3ri9ExOi4yShm5KPMhCjgi2+hsVp0WK5tKzsC9SvrQWz1SmPgTT8s9Ae1MLx bCSynnuM9y8xPmEoHSTCnWrqHrmFq5u2ZYYgZoO6Ge5eI1J+dcZ/O7uN26FYQ7iXaBqzydW7jYC ZhskAUR7NUuKcxyFZfy3F33w== X-Google-Smtp-Source: AGHT+IHywzBtt2Y98fdMxLJNzgOeVD4ffRS+OnKeRVSIAncu9fd1QmO/Ah/ERfqXYWxj/74dSxeZdA== X-Received: by 2002:a05:600c:1c13:b0:477:63dc:be00 with SMTP id 5b1f17b1804b1-47d195893d6mr152090585e9.25.1766505778614; Tue, 23 Dec 2025 08:02:58 -0800 (PST) Received: from smtpclient.apple ([185.8.198.100]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324eaa08efsm28794154f8f.29.2025.12.23.08.02.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Dec 2025 08:02:58 -0800 (PST) From: Andrea Cocito Message-Id: <35A6E88C-FE2C-4EC4-8AED-998D4FA5D965@cocito.eu> Content-Type: multipart/alternative; boundary="Apple-Mail=_55756A4E-AC1E-472B-BDDF-A1E9E59FB8F9" 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: Retrieving the kid/jailname of connected peer for a unix socket Date: Tue, 23 Dec 2025 17:02:47 +0100 In-Reply-To: Cc: freebsd-hackers@freebsd.org To: Peter Pentchev References: <7878EFBC-2BCF-42ED-9BFC-D96DC0DDC23A@cocito.eu> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbKY61frhz3K26 --Apple-Mail=_55756A4E-AC1E-472B-BDDF-A1E9E59FB8F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 23 Dec 2025, at 16:37, Peter Pentchev wrote: > 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. >=20 > What exactly is the threat scenario you are trying to mitigate? Hi, The (theoretical, I cannot imagine it being exploited in practice, but = still the man pages warn against using a pid for any authorisation = everywhere): 1. Attacker starts process with pid P in jail X and performs a connect() 2. Attacker manages to slow down the server in order to delay it=E2=80=99s= accept() 3. Then process P passes the fd to process Q and exit()s 4. Sometimes pid P is re-used in another, unrelated, jail Y 5. When the server does accept()-> getsockopt()-> sysctl() it gets = jail=3DY The idea that a process does connect() and then passes the fd to another = in a different jail is not an issue: I assume that the twi jails are not = co-operating in the attack (if they are each of them could simply use = its own =E2=80=9Ccredentials=E2=80=9D to make any request they want). I was wondering if there is any kernel API that allows to directly get = =E2=80=9CThe jail of the process *currently* connected to this pipe=E2=80=9D= , or at least the pid of the process *currently* connected (neither the = one which made the connect() nor the one which sent some data, as that = could be cluttered by buffering too... so even checking LOCAL_CREDS on = received traffic would not really make the thing deterministically = safe). Thanks, A. --Apple-Mail=_55756A4E-AC1E-472B-BDDF-A1E9E59FB8F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 23 Dec 2025, at 16:37, Peter Pentchev = <roam@ringlet.net> wrote:
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?

Hi,

=
The (theoretical, I cannot imagine it being exploited in practice, = but still the man pages warn against using a pid for any authorisation = everywhere):
1. Attacker starts process with pid P in jail X = and performs a connect()
2. Attacker manages to slow down the = server in order to delay it=E2=80=99s accept()
3. Then process = P passes the fd to process Q and exit()s
4. Sometimes pid P is = re-used in another, unrelated, jail Y
5. When the server does = accept()-> getsockopt()-> sysctl() it gets = jail=3DY

The idea that a process does connect() = and then passes the fd to another in a different jail is not an issue: I = assume that the twi jails are not co-operating in the attack (if they = are each of them could simply use its own =E2=80=9Ccredentials=E2=80=9D = to make any request they want).

I was wondering = if there is any kernel API that allows to directly get =E2=80=9CThe jail = of the process *currently* connected to this pipe=E2=80=9D, or at least = the pid of the process *currently* connected (neither the one which made = the connect() nor the one which sent some data, as that could be = cluttered by buffering too... so even checking LOCAL_CREDS on received = traffic would not really make the thing deterministically = safe).

Thanks,

A.
<= div>

= --Apple-Mail=_55756A4E-AC1E-472B-BDDF-A1E9E59FB8F9--