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
signature.asc
Description: This is a digitally signed message part.
