diff --git a/website/content/en/status/report-2024-10-2024-12/mac_do.adoc b/website/content/en/status/report-2024-10-2024-12/mac_do.adoc new file mode 100644 --- /dev/null +++ b/website/content/en/status/report-2024-10-2024-12/mac_do.adoc @@ -0,0 +1,43 @@ +=== mac_do(4), setcred(2), mdo(1) + +Contact: Olivier Certner + +Contact: Baptiste Daroussin + +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 previous quarter's link:../report-2024-07-2024-09/#_mac_do4_setcred2_mdo1[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 a new manual page for man:setcred[2] and changes to the man:mac_do[4] manual page 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 the manual page 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 the new man:mac_do[4] module cannot be harnessed without modifying these programs to use man:setcred[2]. +* For the man:mdo[1]: +** 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 `/etc/passwd` and `/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 of 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