Hi again olce, i was wondering about what are your thoughts on utilising mac_grantbylabel and mac_veriexec for mdo
as far as i am aware,there shouldn't be any confused deputy problem or any reliance on anything FS related and shouldn't cause any functionality restriction i can give it a try if everything seems right to you > > > 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
