Date: Sat, 06 Dec 2025 07:37:43 +0000 From: Wismos@proton.me To: Olivier Certner <olce@freebsd.org> Cc: freebsd-security@freebsd.org Subject: Re: Regarding PAM support for mdo Message-ID: <GjNyn4BVMVSkM_BG3UgXxY46POlxpNMfeEaNoXUGG-tgM7umHLFlINpUFoB5DeBgbX7bh8hEWpl-qyhHR44PfD_zwji-eaMxrrrtOxPxUaE=@proton.me> In-Reply-To: <24612612.gYbqZ1YImA@ravel> References: <5yH9o0uW628frXojj_IKQVxRqtYT0Z9ZrqQp8eAbNXa3iuQoTT-Nm2zN_yNTc89dzFPvnrYkIIkL5yjmmFZ1z9FmaGpM7_sYJ0t1Ho2ktr0=@proton.me> <24612612.gYbqZ1YImA@ravel>
index | next in thread | previous in thread | raw e-mail
Thanks for the info > 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 my goal is to either have an authentication prompt setup for every time a process from a certain uid is trying to change credentials or to have a some form of blacklist/whitelist to only allow certain processes to be able to change credentials from the response it's clear that a password based authentication prompt is not ideal for mdo currently but perhaps the whitelist/blacklist may work if we were able to figure out how to make it know which process to escalate without introducing reliance on filesytem hierarchy,perhaps MAC/veriexec might be suitable to verify the executable file allowed to change credentials? looking forward to your thoughts and thanks againhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?GjNyn4BVMVSkM_BG3UgXxY46POlxpNMfeEaNoXUGG-tgM7umHLFlINpUFoB5DeBgbX7bh8hEWpl-qyhHR44PfD_zwji-eaMxrrrtOxPxUaE=>