From nobody Tue May 14 07:17:13 2024 X-Original-To: hackers@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 4Vdnjn08QMz5KZbb for ; Tue, 14 May 2024 07:17:17 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vdnjm4wWcz4sn6 for ; Tue, 14 May 2024 07:17:16 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1715671036; 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=IJYEi3NlRtglIXlh0NZ7yY0x6Nk7nAAo3S70kBm+NoY=; b=j2vTnkAgVM2EbA8uU1wNAaeAVmQbfKeUQVFM0ZGBevAdjwTbtiAEVjB63m7jGoZXYvOBOw EN0O2tiOkcA3Ku7VtQ1Tb9RBhJDFpqigyPqf0nNvqa5uc9FU9evljnwOAfZpNb3GSSFWNQ JzfY0YEHLcSqoxMqrC6SMA25a3tnRnkEJJfu0q+lxAGsRjCsRYmt2hZKb3EEcztuwR0BjD l6ggqWt51vYZVrOx06akpmxZkUJF2oyFn7hiLz9I/5pC6PqOFWzzsmiV8naJ/X7Faxer+B yJgZNpvuXI05TZ81NnTZT0bBZPIHGZEi0+zdqSmRz7jIburMn5cjUJy9xvPzrA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1715671036; a=rsa-sha256; cv=none; b=j+p7k0u3pKJF94UrerM9tla5s5knTdVLJxhnzgsJRgQlq/bD8OgoU0TGiVWxDZ7mX7lBq3 LFm64y0UtlmLucUYUihed3p64+KlGai47voPrzTdtw4I85Ulsu8WPAR3xTvk9WvlKMZqmL VkpBfeaCq8/rXXW4zZq3SEHmoJ1p75P/VCS7VpwIHV3nUxhWuYC4uwKnzqpYUL/i+Rw7bE 5Ctn3igA5QHlvdmJ+NHKhHHTF4MOF4LfB2O71O4PigSU9k4fkMi5AAWqn6BGhL1Aeo81tM Oxz4ZGBGFDHmO1YSN4r2SkQ2NhFkDlN1qkmefCG5dc1sBWldUWrjw9sx6I04Bw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1715671036; 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=IJYEi3NlRtglIXlh0NZ7yY0x6Nk7nAAo3S70kBm+NoY=; b=WH2E5qDA6haz3pinefi7MzPUh0h/4Zn3TTtBYp+ouKQdETroHI9e4J5sR+3He3GL9iQm5J LepIfoWsd2GQpgUhMPU7hDTN6mUOnHHhnOMSsgS3qT6oeho7mHom6o3zEc/cFBMPoitFcd EEf2zUePxNPw8Le4gBUlATYG3FgVPGzdPVgsIc3SaN/WBuWFBb1nOUnjL0zSEmINg4a717 8nEnmLMkn3m+Si6B+Wht4MhDgLt8ptq9wQ8wBgAcCetPefLE0YvMKRYe2lOk+rNr3bnOMk w8GCTBqiy4jAyVfGHkbh7Yj3GQTIoJ4TNBQFV9oae0z6t03gkERgECt4WVfS6Q== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (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) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Vdnjm3rh9zc4N for ; Tue, 14 May 2024 07:17:16 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 071136FE82; Tue, 14 May 2024 09:17:14 +0200 (CEST) Date: Tue, 14 May 2024 09:17:13 +0200 From: Baptiste Daroussin To: hackers@freebsd.org Subject: mdo(1) run as another user without setuid bit Message-ID: <2y3wjlrzgxocjxtwnx7avo5xuukkee4lvfjlppqpm3kfbqsrvt@nfszfoezpz3d> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello everyone, This is an idea that I have been thinking about for a while (actually since 2015) and that I have been trying to implement a couple of days ago. On server usage of FreeBSD one thing which often happen is we segregate services with their own users (service_user). We also give access to the administrators of those services via their own ssh keys on their own user (foo) account and of course we want to allow "foo" to run some commands as "service_user" or get "service_user" privileges. Usually this is done via some sudo or some doas configuration which both involved first become root via the setuid bit. In many cases doas or sudo are overkill for this sole purpose. To cover this need, I thought we could write a very simple tool which will leverage the mac framework to make sure we could switch credentials without the need of the setuid root. Here comes the idea of mac_do(4) policy. This is a kernel module policy which allows calling setuid and setgroup from a non root user, according to some policy root and if the request comes from the /usr/bin/mdo binary. The policy are set via sysctl(8): security.mac.do.rules which contains a list of rules separated with coma, for example: uid=1001:80,gid=0:1003,uid=1002:* which can be translated as: the user which id is 1001 can become uid 80 the users belonging to the group which id is 0 can become any user 1003 the user which id is 1002 can become any user. This is only intended to allow full access to the target user, this is not intended to provide fine grain accès like sudo, doas or userv can do. Here is an implementation of this idea: https://reviews.freebsd.org/D45145 Best regards, Bapt