From nobody Thu Feb 22 21:23:24 2024 X-Original-To: freebsd-stable@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 4TgmN5179Qz5BRN2 for ; Thu, 22 Feb 2024 21:23:33 +0000 (UTC) (envelope-from vince@hightek.org) Received: from mail.ngtek.org (ngtek.org [IPv6:2001:19f0:6400:8963:5400:ff:fe09:9585]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TgmN40Cddz420Z for ; Thu, 22 Feb 2024 21:23:31 +0000 (UTC) (envelope-from vince@hightek.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of vince@hightek.org designates 2001:19f0:6400:8963:5400:ff:fe09:9585 as permitted sender) smtp.mailfrom=vince@hightek.org; dmarc=none Received: from [170.39.28.55] (helo=marble.hightek.org) by mail.ngtek.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1rdGXM-0001OE-G5 for freebsd-stable@freebsd.org; Thu, 22 Feb 2024 15:23:24 -0600 Received: from vince by marble.hightek.org with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1rdGXM-000C4U-TU for freebsd-stable@freebsd.org; Thu, 22 Feb 2024 15:23:24 -0600 Date: Thu, 22 Feb 2024 15:23:24 -0600 From: Vincent Stemen To: freebsd-stable@freebsd.org Subject: Re: gpart device permissions security hole (/dev/geom.ctl) Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TgmN40Cddz420Z X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.901]; FORGED_SENDER(0.30)[vince.bsd@hightek.org,vince@hightek.org]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:6400::/38, country:US]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[hightek.org]; FROM_NEQ_ENVFROM(0.00)[vince.bsd@hightek.org,vince@hightek.org]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] On Thu, Feb 22, 2024 at 01:12:23PM -0000, Peter 'PMc' Much wrote: > On 2024-02-17, Vincent Stemen wrote: > > > > I have been a Unix systems administrator for well over 35 years and It's not > > uncommon for administrators to belong to the operator group for restricted > > admin tasks. It is completely unexpected to discover the user can wipe out > > the whole system. > > Removing the number plate from your house doesn't destroy the house. > It only might stop it from being accessed by people. BTW, correction to my original statement. The operator can only modify unmounted partitions. So any unmounted partitions or partitioned drives on standby for failover, backups, etc, can have their partitions deleted or changed, which will certainly stop access to the data on those devices. So stopping access to your data isn't much different than destroying it if you can never find it again. If you have a house somewhere in the country, with no address, other than perhaps what state it is in (which drive), have fun finding it. So your analogy is a distinction without a difference. Not only that, if the partition table gets modified without the sys-admin realizing it, and it gets written to, it most certainly can destroy the data. The way it is currently, there is apparently no way to grant individual permissions to a user, through the operator or any other group to, for example, partition a thumb drive, because permission to modify partitions is controlled for all geom devices via the one /dev/geom.ctl file. We also discussed this issue more extensively in the forum. https://forums.freebsd.org/threads/gpart-device-permissions-security-hole-dev-geom-ctl.92397/