Re: Regarding PAM support for mdo

Hi,

>> 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.
As a user of mac_do(4)/mdo(1), I strongly believe the current 
implementation of mac_do(4) is perfect. IMHO and only IMHO, any change 
to mac_do should NOT break these expectations below to mac_do(4), which 
are the reasons we use it:

  * No dependency on a configuration file (sysctl-based)
  * No filesystem dependencies (including the setuid bit)
  * Jail inheritance support
  * Straightforward ucred-specific syntax

Community appreciate improvements to mac_do; however, any change that 
affects the above reasons will defeat mac_do’s main purpose and turn it 
into kernel-to-system glue, making it of little to no value to its users 
compared with doas(1).

I have a few suggestions:

  * Any addition or improvement not related to ucred should be in
    another sysctl node to not break compatibility.
  * I found that learning current mac_do(4) after reading its manual
    requires try-and-error to understand its function. New users first
    have to unlearn things about doas(1)/sudo(8) and understand that
    mac_do is strongly explicit in its credentials. which is
    good. Therefore, it must be heavily documented considering it has a
    security effects too.

I believe the RFC1925 statement about protocol design is also applies to 
kernel modules.

/(12) In protocol design, perfection has been reached not when there is 
nothing left to add, but *when there is nothing left to take away*./

Thank you for working on mac_do.

-- 
spmzt