From nobody Tue Dec 23 20:51:45 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 4dbRyJ5zwSz6Kqws for ; Tue, 23 Dec 2025 20:51:52 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 4dbRyJ3Hkvz46Bw for ; Tue, 23 Dec 2025 20:51:52 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-37fdb95971eso38870661fa.1 for ; Tue, 23 Dec 2025 12:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766523109; x=1767127909; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=zLH/quaQHGqVPeB2nA57rLetD2e9cC9bdVfedyjouEo=; b=f+Kw9z/uJdgmL2fVaZ8NVxXTXEfI1CgrIh/fPO10ezPVnDx9oiWmV/KpbQRiUeBQXa tRBAMZQ5uviJnZqpHBBNOxZK1zrUrZH6auJtnrjHWXdEdL4l8PuhgfPXboGb3StJuUsT E8WASdkmOAU8fwp71s+HRf+4gvxVyYM0zwQ1b2Du9DMmAlX6qspmCQwBki09Fr2C/3j1 DYf5auYV8YV7L94zht9TynFVexNDPfNN8115xq78f3SvDv48sPl3+rtf7QcHRzuyBmvF UctoyPO/BkNKv9914g2xCOQuxZrBNEYGL1YiuEKA3rUZlgnZEO20P43FSc9VtE6Rtc5L zrFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766523109; x=1767127909; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zLH/quaQHGqVPeB2nA57rLetD2e9cC9bdVfedyjouEo=; b=rjayWhO0MgyUpZ9rk5RY9OdMhg36PkLBuSsGTNSiWI+wYTtNzx/BKIu92nGLMttA80 7KeC6q9JM145Pb8maBz0ABbnteucmLitgIZXZc077JmX39efkkVVj53vkk7StAiCNpJB iA3G0hd+LPr/9D/PwBQvR+iuSNArYL0xSYGb83guktlPN6M/V91ABVis87pnFCYUq0uY Ux1lCmcdmVLN9pDc5vdHduNVppaFNjCKTCVEn/btk/HjA3TeVzCzuGFOJvifBLVK5o4H qdUSrHIcLwh9g/kP+PNm2mfyW8/oftsV2xnXf2x4aB+L3XZ64CnFdU/lp86tm7TZSudR y9Sw== X-Gm-Message-State: AOJu0YzIx0jWfnEh3Ty0Gmo7TIk3dCnxMnKJEYLKIai7IswfDKK05Q4e cpHIcbSPfwuE0o5WNoop2S1FdpZu1MGM31MfEGQtHOkMmP6xVP9hABNEOJj4aA== X-Gm-Gg: AY/fxX6CLczgX39oMGPuiES3NIEByLEzvrwE43N4xDTmh+wxb1WOKwqkMYjCH4OHMz3 7UKDMBQK9J6g2WkvlL+WfL94fD5bZXCmemPfzcJn+rfBKrmniUmODBBxBnYU131cRQ+SBIwfTD0 06TWpjxC46cBlvJYyGDGUje0d9wmABxe5uAjK5SBA84RSJMV6mIAyEn85y0KUCqlMD2FLHPqgyL ZU8j2eafS5X+WLsHK1xTFRJ9vCWswf7lJF03iysop9hibjRd3P0rm5sPdU8XKqfNyzPJAZcTkb4 CTwjdshGDC11g2/RwoNDGE5WsdkdXE835L8kbC+gt9BHCZDgQBOgQOasyRPT+9yDGasCKLJGEPx 66fQEeHpnLmYEUnp3IxpLKvqN8l81jxm6n5heXdDNvwlMzB7laMp8WrhwZg7tidU8kSbhu37dog 2xHWz25rHO06DkYpzQ6rVW0B0oGB6IlyKhOasKCXdLl5DydGuzFYzzVg== X-Google-Smtp-Source: AGHT+IGtwqn5ZrR4zHpW0E1R0udzlhAXnu/+PDM+sameWMDGV+n1N8sPPfWnl4bp7jy2AfVgkqPeDg== X-Received: by 2002:a05:651c:544:b0:37b:95ee:f605 with SMTP id 38308e7fff4ca-381215af948mr55797301fa.10.1766523108961; Tue, 23 Dec 2025 12:51:48 -0800 (PST) Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-381224de67csm38287761fa.9.2025.12.23.12.51.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Dec 2025 12:51:48 -0800 (PST) Date: Tue, 23 Dec 2025 23:51:45 +0300 From: Vadim Goncharov To: Andrea Cocito Cc: freebsd-hackers@freebsd.org Subject: Re: Retrieving the kid/jailname of connected peer for a unix socket Message-ID: <20251223235145.33f8cf3d@nuclight.lan> In-Reply-To: <7878EFBC-2BCF-42ED-9BFC-D96DC0DDC23A@cocito.eu> References: <7878EFBC-2BCF-42ED-9BFC-D96DC0DDC23A@cocito.eu> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.4) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 4dbRyJ3Hkvz46Bw On Tue, 23 Dec 2025 13:54:31 +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 th= is > =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_PROC_PID, > static_cast(pid) }; sysctl(mib, 4, &kp, &len, nullptr, 0) 3. I map t= he > 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 iss= ue > that potentially could be exploited as follows: a. A process with pid P i= n 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. Pr= ocess 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 informati= on >=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 is > 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 nothing from the kern= el > exposes the =E2=80=9Ctimestamp when connect() was called=E2=80=9D, so I a= lways 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 Cro= w-http? =20 What about trusted per-jail proxy which has separate socket in each jail? Or even just per-jail sockets without null mounts. --=20 WBR, @nuclight