From nobody Wed Oct 09 16:55:44 2024 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XNzXw1k2xz5YlQg for ; Wed, 09 Oct 2024 16:55:44 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XNzXw1B4Dz42XT; Wed, 9 Oct 2024 16:55:44 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728492944; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=eUTpw3Jqj4gKetkV3qBkZHD9Y7tfGUjtZ9v9V4mqUBA=; b=Fyuo3fDdkqbakV3KpBrAz1bov6GxNouUZHmdQCs57Gr9KLTjdkpYC/h0XbAWY8ygcEh6UL K02vKSCcK4b1YciWqPd/6ryqVO39FOKQsZFysJyrsBmRyMCEwwAIyTDC6p9z0osullXk8T TX+NXR0lFYexEm8IwJS9uxSo2pXTTSzPRRMGgRLho7Oc2SAOZPSl2lKxglmHf7eZi247vE m9mWKhKM5fFX1MtDrLXaWRj8tG9aomJzeX1OWlNAOVCmBHWNxN6wky/TWPQqscPsfmvN2+ oL2TGOigk9XtPY6M+PxOgFs4BTKvh0jZaRI4Vkjkz6sKrhCzmFzCcqPmVriHSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728492944; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=eUTpw3Jqj4gKetkV3qBkZHD9Y7tfGUjtZ9v9V4mqUBA=; b=yG6dchkUgPNAnxQlJM0Zn4DEfvt74r26OOrSjGF5WB47l3Ie4aMEaAYpSWih2NzmSTTz82 I1u5937GURbwOM97K1Sy4CSFVsEF3h9JPWwoUJ7JwS9/RUb1f0dmgrd34KsEs/aabwVj08 4zzfBYDq1RHHqbqCir7+GCtuZu2jdbElPIorFn2OXbu9wSIEEQ+ZVhBU5djQSLEAtUiDJY h/C93leiXSu7zlHJVgFWjzn0sJ8GrRxHiEo4qSWIGhsb3H2RVd79LQ/A/87gsRUNMb39v2 8QI+DUbDnTGWIN/lHFyQS/6aLx0v4szT0GZx40do450lwPc9nDmIB+LcIEpJzg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1728492944; a=rsa-sha256; cv=none; b=umZmv49Yb7zw6jDVXnehPK5p/Q/Y15L0N8HWm4mUvvTureo99gX9bx9L1I+4I5veBSVmP9 eHxbyVpWFa+E7fctxS9hBqSydeAyXuY8EEEhI1eTKAJqFhhK4eMwa+E/m3m0rv+rhRODyb P09dnKzG24TnO7Ll1jVJuG1U1rnoCkwnBvlz1EODZVddQLo8w7wzJtWJQ6LViAWIIkJe/x tUfNek+5VxJxvgZJHiJwwo6+iQjc7ME/BSvSjM2ljeQOOCP+1dlAIRQNd/gox833NAQjHq VW9xNKbes4YZC3AsYI6dpUYIsG94BloCMoLeOo5MMeh3LxNB3keoTOoqzjcLNg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4XNzXw0n8TzMLd; Wed, 9 Oct 2024 16:55:44 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.18.1/8.18.1) with ESMTP id 499Gti5l097872; Wed, 9 Oct 2024 16:55:44 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.18.1/8.18.1/Submit) id 499GtisK097869; Wed, 9 Oct 2024 16:55:44 GMT (envelope-from git) Date: Wed, 9 Oct 2024 16:55:44 GMT Message-Id: <202410091655.499GtisK097869@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Olivier Certner Subject: git: 6676583b3f - main - status: 2024Q3: mac_do(4), setcred(2), mdo(1) List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-doc-all@freebsd.org Sender: owner-dev-commits-doc-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: olce X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 6676583b3fb440106f87b1a724494ab599f48a01 Auto-Submitted: auto-generated The branch main has been updated by olce: URL: https://cgit.FreeBSD.org/doc/commit/?id=6676583b3fb440106f87b1a724494ab599f48a01 commit 6676583b3fb440106f87b1a724494ab599f48a01 Author: Olivier Certner AuthorDate: 2024-10-09 10:51:12 +0000 Commit: Olivier Certner CommitDate: 2024-10-09 16:52:26 +0000 status: 2024Q3: mac_do(4), setcred(2), mdo(1) Reviewed by: bapt, salvadore Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D47024 --- .../en/status/report-2024-07-2024-09/mac_do.adoc | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/website/content/en/status/report-2024-07-2024-09/mac_do.adoc b/website/content/en/status/report-2024-07-2024-09/mac_do.adoc new file mode 100644 index 0000000000..c06e2933f2 --- /dev/null +++ b/website/content/en/status/report-2024-07-2024-09/mac_do.adoc @@ -0,0 +1,39 @@ +=== 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. + +Traditional programs for credentials change have to execute preliminary operations as root (if not as the effective UID, at a minimum as the saved UID). Some of these programs (e.g., man:sudo[8]) have lots of lines of codes and comprise features (e.g., loadable security modules) that can be dangerous from a security standpoint. +Thus, they have a non-negligible attack surface and are difficult to prove correct. +Additionally, in most scenarios, the extra features they bring are not necessary. + +More generally, the threat model for the man:mac_do[4] kernel module part is that of compromised userland programs, be they credentials changers or credentials providers ones. +This stance implies that calls to the kernel's credentials-changing API must be monitored by the kernel without upcalls to userland. +In practice, man:mac_do[4] must be configured beforehand by the administrator to indicate which transitions of credentials are valid (through a man:sysctl[8] knob, `security.mac.do.rules`). + +Currently, the companion userland program, man:mdo[1], is the only one that can be authorized to proceed by man:mac_do[4] (for now, based on the executable path). +This tiny program simply establishes the new credentials via calls to man:setuid[2], and optionally man:initgroups[3] (calling man:setgroups[2]) and man:setgid[2] (if `-i` was not passed). + +The resulting set of groups is either that of the target UID based on the password database, or that before the change in UID (when using `-i`). +The second alternative can be a security hazard in some cases (as the effective GID is not changed either), whereas the first contradicts the threat model above. +The current man:mac_do[4] rules specification indeed only allows to express simple UID transitions towards explicit UIDs from other explicit UIDs or GIDs, without taking into account groups. +Consequently, the kernel module currently cannot check the content of man:setgroups[2] and man:setgid[2] system calls' parameters, relying completely on man:mdo[1] passing the right information. + +A new version of man:mac_do[4] has been in the works for approximately a month. +Besides fixing concurrency, per-jail settings and MAC policies composition problems, it features a revamp of the rules specification in order to make it possible to finely control which groups are allowed in the resulting credentials. +Notably, primary and secondary groups can now be specified independently, and for the latter, GIDs can be tagged as allowed, mandatory or forbidden. +A special alias, `.`, can be used to indicate the current process' UIDs or GIDs depending on the context. + +These new features imply that the man:mac_do[4] module is able to apply credentials change at once, since the allowed final credentials depend on the initial ones through the configured rules. +The traditional userland interface (e.g., man:setuid[2], man:setuid[2], man:setgroups[2], etc.) is at odds with this requirement as it necessitates multiple calls to reach the desired final credentials, making the process pass by several successive states that themselves may not be allowed by man:mac_do[4]'s rules. +We overcome this limitation by introducing a new system call, man:setcred[2], which allows to request arbitrary transitions of credentials at once. +Beside its usefulness in conjunction with man:mac_do[4], it has the benefit of simplifying coding of credentials change in userland. +Since it is also extensible, it may have the potential to be adopted later by other systems. + +Pre-requisite changes are currently under review (see in particular revisions link:https://reviews.freebsd.org/D46886[D46886] to link:https://reviews.freebsd.org/D46889[D46889] and link:https://reviews.freebsd.org/D46896[D46896] to link:https://reviews.freebsd.org/D46923[D46923]). +The bulk of changes in man:mac_do[4]/man:mdo[1] proper will soon be pushed under review as well. +An older version of the full series can be seen on link:https://github.com/OlCe2/freebsd-src/tree/oc-mac_do[GitHub]. + +Sponsor: The FreeBSD Foundation