From nobody Fri Feb 23 11:49:18 2024 X-Original-To: geom@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 4Th7b269mfz5CKKH for ; Fri, 23 Feb 2024 11:49:18 +0000 (UTC) (envelope-from bugzilla-noreply@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Th7b21ryMz4lF7 for ; Fri, 23 Feb 2024 11:49:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708688958; a=rsa-sha256; cv=none; b=kDvuGlIctHyaP910KJLQNo+O1KUPZR4HxEd6Q5icI/iMSapV0bbjDjfg2LpJHwR0oXgdAf Uv9rbCR4imuYRNdQKn6MdCfnTQu5zoyTBXznsE6RfPrGuchpdb2ihYhmTxaMQqHAZH7PBV TiyFkdyk16vgjtiVS7E5hnI929mrEWay+3Ei/XdMcu7076jljAF/YGUmC2dmKflb76YXsQ THt0OfgKty8uubPRbhgVn6zs6QR97oNd4BXOMHyFJ8SRdVbMeFiFgx8u74cjaTttYTeoo0 nC3b0M9/aAK3DLl1vKROwZzwIDNoHP7mTvBNrLDqeZ8Ve4wzjTrFkJk4zecDMw== 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=1708688958; 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: in-reply-to:in-reply-to:references:references; bh=U6ImwwzRvkRTRHDb+HRogE1ZouX5oNH6eqhMh2EXSy0=; b=Hd+/C/gTswIUQdIMXTUZOtji3hbt4LJYFbaRvTCiytPpzpWkqw6WT0KFgqjhSP8kWXurUW By8rVyo4gzpqX0vUStMnmetCZKCAxYWIYEAA9k8y2O1XWE/CvNNuT5MFpGGdRXR2roDeV/ G0KlOH10g5VzBHA82d8mVVUD9gFAgvEf63BxoE8JLj97tpoYBnl23FTFaTCX2vpl7NUs1n cmYBl8ktbWdIzgE5Hf4zNxal6vcTu7Q+OFF1GvgwAN5sD0rllAI/6Z8rspecJg4ZcgCGFB nhX28eTyYEEj0hk08arqDf+oxAatwKbsMCPcOvsvmEZKl8RHfOubAbQ2ccTM6g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 4Th7b20fcgzDsK for ; Fri, 23 Feb 2024 11:49:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 41NBnIvI081971 for ; Fri, 23 Feb 2024 11:49:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 41NBnIqR081966 for geom@FreeBSD.org; Fri, 23 Feb 2024 11:49:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: geom@FreeBSD.org Subject: [Bug 277228] Device permissions security hole with partitioning (/dev/geom.ctl) Date: Fri, 23 Feb 2024 11:49:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: security X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: phk@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: geom@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: GEOM-specific discussions and implementations List-Archive: https://lists.freebsd.org/archives/freebsd-geom List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-geom@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277228 Poul-Henning Kamp changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phk@FreeBSD.org --- Comment #1 from Poul-Henning Kamp --- Oh boy... The 'operator' group predates FreeBSD, and I speculate that the intent was = to enable non-root users to backup filesystems with dump(8), which reads the r= aw disk, rather than go through the filesystem. See for instance 386BSD's MAKEDEV script, which grants 'operator' read acce= ss to disk devices: fd*|wd*) umask 2 ; unit=3D`expr $i : '..\(.*\)'` case $i in fd*) name=3Dfd; blk=3D2; chr=3D9;; wd*) name=3Dwd; blk=3D0; chr=3D3;; esac case $unit in 0|1) mknod ${name}${unit}a b $blk `expr $unit '*' 8 + 0` [=E2=80=A6] chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h] chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h] When I implemented DEVFS (3f54a085a60) I retained those permissions, which = is why ``sys/conf.h`` knows the numeric gid of the operator group, and for sim= ilar reasons it ended up knowing about a dozen non-zero uids and gids, in order = to stay compatible with userland and user expectations. I did consider having DEVFS expose everything as ``600 root:wheel`` but the= re were no sane way to have a trusted program in userland fix the permissions = to what tradition and users expected. (Also: RAM was /expensive/, so adding another background process was unthinkable.) GEOM had a much tougher row to hoe and it took a number of gyrations to fin= ally get access to "on-disk metadata" such as disklabels, MBR's and other stuff sorted out, while trying to remain compatible with what people had on their disks at the time. Along that route I tried to get rid of the magic ``GID_OPERATOR`` in the kernel, but as (0a2ece0481909f7) attest, people relied on it still. I do not recall anything depending on ``/dev/geom.ctl`` having ``640 root:operator`` permission, and I suspect it may have gotten those as a side effect of reusing common geom functions. Now that we have devd(8), we could zap ``UID_*`` and ``GID_*`` from ``sys/conf.h`` and move the adjustment of permissions to userland where it belongs, and maybe we should, or maybe it is not worth the effort. However, for multifunctional "control devices", typically named ``*ctl``, t= he file system access control is insufficient, because only the parameters to = the actual syscalls can tell if something innocent like ``gpart show`` or privileged like ``gpart destroy -F`` is being attempted and jails are anoth= er complication. The ioctl(2) implementation magic know some things about "read/write/both" = for the ioctl(2) argument, but unfortunately that does distinctions do not read= ily map to "harmless" vs "consequential", the way it may have back in the 1980'= ies. And we are not just talking ``geom.ctl`` here, other magic devices like ``mlx5ctl``, ``cam/ctl``, ``sa%d.ctl``, ``apmctl`` probably also grant ``GID_OPERATOR`` near-root behaviours. My suggestion would be to modify ``sys/conf.h`` to define ``GID_OPERATOR`` = as zero, and if nothing very important breaks, leave it like that. --=20 You are receiving this mail because: You are the assignee for the bug.=