=== mac_do(4), setcred(2), mdo(1)

Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr> +
Contact: Baptiste Daroussin <bapt@FreeBSD.org>

This project aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging our MAC framework.
For an overall presentation, we refer the reader to the link:../report-2024-07-2024-09/#_mac_do4_setcred2_mdo1[previous quarter's report].
As this is a progress report, we only recall the outline here.

In a nutshell, this project comprises two components:

* man:mac_do[4] is the kernel module that checks credentials transition requests and authorizes those that match rules configured by the administrator.
* man:mdo[1] is the userland program playing the role of a mediator between processes wanting to launch other processes with changed credentials and man:mac_do[4], whose function is to authorize only specific such changes.
man:setcred[2] is the new system call at the interface between them.
It enables userland to request various credentials changes atomically, allowing man:mac_do[4] to base its decision on the transition between the initial and desired final credentials.

Both prerequisite commits and changes in MAC/do proper have been reviewed and all commits have finally been pushed to FreeBSD's main branch, including documentation in the form of a new manual page for man:setcred[2] and changes to the man:mac_do[4] one to match the new man:sysctl[8] knobs and rules syntax.

Rules can now express finely which groups are allowed in the resulting credentials for a given UID or GID, notably making it possible to specify which target primary and supplementary groups the final credentials can, or must, or must not include.
Please consult man:mac_do[4] for a description of the new syntax and examples.

Future work, in no particular order and timeframe, may include:

* For the man:mac_do[4] component:
** Currently, it can only grant credentials transitions for processes spawned from the `/usr/bin/mdo` executable.
   The possibility to tweak this path may be interesting for custom thin jail layouts.
   The ability to have several such paths is one of the missing pieces to be able to use man:mac_do[4] in conjunction with other credentials-granting programs such as man:sudo[1] and man:doas[1].
** man:mac_do[4] currently can only grant new credentials if they are requested via the new man:setcred[2], as it needs to see the current and desired final credentials to make a decision.
   However, each call to traditional and standard credentials-changing functions, such as man:setuid[2], man:seteuid[2], etc., can be considered as a (limited) full transition on its own, which man:mac_do[4] could decide upon.
   This functionality could allow to more finely control transitions to `root` and, combined with that of the previous point, to install and use credentials-granting programs without the "setuid" bit.
   However, the full power of this new man:mac_do[4] module version cannot be harnessed without modifying these programs to use man:setcred[2].
* For the man:mdo[1] component:
** The credentials transitions that can be requested are fairly limited compared to what man:mac_do[4]'s rules can allow.
   It would be useful to make it possible to:
*** Specify any list of target groups (primary or supplementary), possibly based on user names (with the implicit list coming from the contents of [.filename]#/etc/passwd# and [.filename]#/etc/group#) but allowing some tweaks (such as excluding a particular group in the final credentials).
*** Allow changes of groups only.
*** Request a password before calling man:setcred[2] in certain cases.
    This weakens the security paradigm of the man:mac_do[4]/man:mdo[1] combination, as it would now rely on userland for part of the gating process, but seems acceptable in many cases.
*** Grow a mode producing the target part of rules corresponding to the contents of the password and group databases for some users.

We welcome any feedback on this new version and the future-work list above.

Sponsor: The FreeBSD Foundation +
Sponsor: Kumacom SARL