Date: Sat, 06 Dec 2025 00:02:14 +0100 From: Olivier Certner <olce@freebsd.org> To: freebsd-security@freebsd.org, Wismos@proton.me Subject: Re: Regarding PAM support for mdo Message-ID: <24612612.gYbqZ1YImA@ravel> In-Reply-To: <5yH9o0uW628frXojj_IKQVxRqtYT0Z9ZrqQp8eAbNXa3iuQoTT-Nm2zN_yNTc89dzFPvnrYkIIkL5yjmmFZ1z9FmaGpM7_sYJ0t1Ho2ktr0=@proton.me> References: <5yH9o0uW628frXojj_IKQVxRqtYT0Z9ZrqQp8eAbNXa3iuQoTT-Nm2zN_yNTc89dzFPvnrYkIIkL5yjmmFZ1z9FmaGpM7_sYJ0t1Ho2ktr0=@proton.me>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----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-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24612612.gYbqZ1YImA>