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 again
