From nobody Fri Feb 23 23:15:34 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 4ThQpx2x8Sz5BjkS for ; Fri, 23 Feb 2024 23:15:37 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (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 (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ThQpw4SHQz4JC7 for ; Fri, 23 Feb 2024 23:15:36 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuta.io header.s=s1 header.b="ad2FN/9z"; dmarc=pass (policy=quarantine) header.from=tuta.io; spf=pass (mx1.freebsd.org: domain of henrichhartzer@tuta.io designates 81.3.6.162 as permitted sender) smtp.mailfrom=henrichhartzer@tuta.io Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 8567FFBFB7E; Fri, 23 Feb 2024 23:15:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1708730134; s=s1; d=tuta.io; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=VatLyysDg8tmmsaOw4Qu15qMTW+vL94d2thtHaOy590=; b=ad2FN/9zUAshLUnZ4s2RckW9ZiYZJOVZdYVFbYphhRIFAVaMhp6vTwah2zh1WpgH YG5qSzvIm+/GBzRhcO+AywP6kdpJCM1lcqqBobCQNmeaxlWcjcQqDh4pHOrAn3/SniX bznEd5BDiBP02zmZ6j1M0OkRHBFoOYvbkTUU8cZWYhUPRTkKwDzBjoQ89LVQFxbJStQ MZ46l3dvY9nwx8QnzbIGp0soh9FBojGg5ltLRAbqTW8FzvrUDhojuQ7c+1KVI+1zpkH qalktUlPTeV14UdOrC/4+XVrZ0oYGOLqW5rBsIgcHUFsRg/Dewk1Yudufq5dR/7HbFN QGPP/+jhNQ== Date: Sat, 24 Feb 2024 00:15:34 +0100 (CET) From: henrichhartzer@tuta.io To: Vincent Stemen Cc: Freebsd Stable Message-ID: In-Reply-To: References: Subject: Re: gpart device permissions security hole (/dev/geom.ctl) 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=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[tuta.io,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tuta.io:s=s1]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[81.3.6.162:from]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tuta.io:+] X-Rspamd-Queue-Id: 4ThQpw4SHQz4JC7 I agree that this doesn't make much sense. Read only access should not imply any kind of writing functionality. What would it take to change this? I'm not familiar enough to say. Thanks for posting, Vincent! -Henrich Feb 22, 2024, 21:23 by vince.bsd@hightek.org: > 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/ >