From nobody Fri Dec 5 23:02:14 2025 X-Original-To: freebsd-security@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 4dNRjC70Nkz6Jd4f for ; Fri, 05 Dec 2025 23:02:23 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dNRjB4MSyz4Fhw; Fri, 05 Dec 2025 23:02:22 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764975742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=W0J9GTB8+QBYJzGXanT2OqloIEw55IXy098nkihicic=; b=C9bIX87jzIJYUPQZy8Idd4/PNco+X4PvKQilF+0nkj0xlTyt2Gciqdz7G2qu9QzNVSYlVO ftYVqPkCJGWpApVj2XUrnNaNHTJ2SjhiXuOO6BLGZYEHuTo7LAsq3FnrbbQE6DecKjyTRe bCdxJJsDRUnRXv3K4sDoqOBHK2PqOs99S6OKKYhOt2KEp4uqN92s5rqxZNOJuZquJz14BA oq17ouv/PXKsvQhls9QxI7GL8T2gZKPZG6OcDqrWzIwcGdifLrmXAINHF0h3EiQ6TFU5G9 IHbNqgom573Gl1mOBaA9buWxVALuRVGupuTCO8+6eVW0tPBrjCTnHVk0Laistw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764975742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=W0J9GTB8+QBYJzGXanT2OqloIEw55IXy098nkihicic=; b=V5GzeHLuFX+wW/iRFf6uFPU9z07i7cYQne6DUtijo2f+t2enAnI6MEOtE/h8Wsb0Ou0gJm B2kWd/FHNP6ixGsIrMS9F2PT4Ms6fBxC0nIk1Ru7kUfCb0eDjy35rIgNUtlMYbErqgBKG3 h0budV+7lNK/7QqrAjrUGRtGgZSQI0jFea+5ppX76YLLt6ENBxQ3u3OdytacqXttB7eYiy rB9VzvGE65mHkIMpuLIbpW9FfqnmWMm6gJRLSlYFNiglrWIWrtQM40UKU6BJT5G7InWN06 CEipTpr3EzM87isofRUB+XB4rpeD8UQrLIMuai5mFfMMYeDsyFrZqfZdoX62+g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764975742; a=rsa-sha256; cv=none; b=Bi45LlWaSTDLcN8+NEwEgUAiovz189C1vFxsAsPWUDMXOXd77kcgDZhQk2I6EDeCoHwTo7 Pi7FvaY1v2D/W5f14qAeKatQeASqNZX/7OEwoRKqpMvI0HDqqgVCfsBd7tYcmLlU9vA/Du +bhFa2jkEwc5t79qn76pvtjP5XckdluSMCY6ZxOuJrzSS9b9xQeruBxBshSYmYCeZsO98D Hbq5qYR9yNSNNLvdCKieHE8ZZqw2U1OHIAz7KPe2s7CuFi7R0VRLLhNd7P/pswz24K28PV xz6gxVXiKd0MHrNhZdV8/3K4AktKsWeyO8FM7TSr2FMl6a79xrxL8YbLK54Ftg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dNRjB1NK3zZKH; Fri, 05 Dec 2025 23:02:22 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: freebsd-security@freebsd.org, Wismos@proton.me Subject: Re: Regarding PAM support for mdo Date: Sat, 06 Dec 2025 00:02:14 +0100 Message-ID: <24612612.gYbqZ1YImA@ravel> In-Reply-To: <5yH9o0uW628frXojj_IKQVxRqtYT0Z9ZrqQp8eAbNXa3iuQoTT-Nm2zN_yNTc89dzFPvnrYkIIkL5yjmmFZ1z9FmaGpM7_sYJ0t1Ho2ktr0=@proton.me> References: <5yH9o0uW628frXojj_IKQVxRqtYT0Z9ZrqQp8eAbNXa3iuQoTT-Nm2zN_yNTc89dzFPvnrYkIIkL5yjmmFZ1z9FmaGpM7_sYJ0t1Ho2ktr0=@proton.me> List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart55254552.J2yNMGElB9"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart55254552.J2yNMGElB9 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner To: freebsd-security@freebsd.org, Wismos@proton.me Subject: Re: Regarding PAM support for mdo Date: Sat, 06 Dec 2025 00:02:14 +0100 Message-ID: <24612612.gYbqZ1YImA@ravel> MIME-Version: 1.0 Hello, > so i would be really glad to know if the reason were some blockers or security wise issues i am not aware of Yes, there was a reason: It doesn't fit in the current mac_do(4)/mdo(1) framework in a straightforward manner. mdo(1) is not a setuid executable (a feature), which basically means that PAM, which expects to be root, is unlikely to function correctly. E.g., it's impossible on FreeBSD for a non-root user to validate some password against the database, as 'master.passwd' is only readable by 'root'. CAPSICUM programs have the related problem of not having enough privileges for some operations, but their way out, libcasper(3), currently wouldn't solve our problem (still not enough privileges to access the password database) and code would have to be written there for some PAM functions to be accessible through it (it's mostly and perhaps only the authentication phase that could interest us in PAM). Using PAM also means starting to rely on the filesystem hierarchy, with implications in terms of security when leveraging jails and chroots (confused deputy issues, as described in August on hackers@). Currently, mdo(1) does not read any configuration file at all, and thus is not subject to such problems. They are however easy to avoid (by leveraging P2_NO_NEW_PRIVS; at the price of functionality restrictions). What is your goal exactly? Having a simple program like doas(1) replacing sudo(8)? I'm evoking a number of possible mac_do(4)/mdo(1) evolutions in an article in the next FreeBSD Journal issue. One may be to have another executable, with the setuid mode bit set this time, that could leverage PAM with full privileges, and drop them the rest of the time until calling setcred() (this code could be share with mdo(1)). Another is to have an ad-hoc authentication mechanism, but then we would still need a mechanism to safely read a password database, e.g., communicate with a privileged server, which still remains to be written. There are number of other solutions with different advantages/drawbacks. The following steps are unclear, and mainly depend on user needs/feedbacks. Thanks and regards. -- Olivier Certner --nextPart55254552.J2yNMGElB9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmkzZHcACgkQjKEwQJce Jidm6g/7BjG9ZDY2C+/i+k3FRfPha0M/BA1C1x1bUka5tit9eZGLbYeQYgkKDOCq WUZ//sWJ9JNDdYCFEglQvnA/H1J9nV7150XjgQ8Wqh5GTSAjsUL2A5B7eC6JQfnV mEAbLrTG017CEDZKmMJekscC7lvScJpjdd/ZkeBvqqz7XQ7ZgY3EdyZv6d4ynreP ch+7Je8NmtMr0y0VM8okGvrdkvG9/2GSa68ofZqNS7sBfMHQywTn5LWejB/Sfm6O X3yx96WCRekD8x/5/FhZ1OfKd5VZFzmm7ebAS2qsdKDtaPQEe9QWaA1FDtgQbK3F muc//MNuwT9E6fGArUrVpD+DQS5JbpYOdtLN0FhzSjlnWYecgomAtog0iB/+ICF9 OYeKy8o69QDRmy1ITCEyNxvsCFDXFhaXmO/Mkg2oHTdHpmaOE1Jr/UjemKYK+0kS W43U0AQQswmtK+QQf26EY/lQXZaAQ3LXoYviinJNkk0CHr+JuwegWD3PA87r/Kjk ZTliescnajjHEAhazRi6M+uBzG3JGWVNBgTEKZnhnpV0gsmUtkAI73fA723EOhBx BoLA+QwY7rNZ2qjvlln7VVk+QTJPJsRHsjRfKHEbihJqzV0LUXiZjq8giTaeMHc8 g9EZzHOGOAVMA1GHDh26SuMGNqlD5hFYgzGUIVAhYjMKG8tmd4g= =ti+4 -----END PGP SIGNATURE----- --nextPart55254552.J2yNMGElB9--