From nobody Sat Feb 24 15:40:00 2024 X-Original-To: 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 4Thrfz58gKz5B1SS for ; Sat, 24 Feb 2024 15:40:11 +0000 (UTC) (envelope-from SRS0=G+MS=KB=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4Thrfy6wd5z4Qt5 for ; Sat, 24 Feb 2024 15:40:10 +0000 (UTC) (envelope-from SRS0=G+MS=KB=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quip.cz header.s=private header.b=Re9biVJf; dkim=pass header.d=quip.cz header.s=private header.b=LUbDcgML; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=G+MS=KB=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=G+MS=KB=quip.cz=000.fbsd@elsa.codelab.cz" Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E7619D788F for ; Sat, 24 Feb 2024 16:40:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1708789201; bh=tnjzZMfgC+jzidF82t/9TfDpvvjCqAeCWQQZycOvZQw=; h=Date:Subject:To:References:From:In-Reply-To; b=Re9biVJffsqAXFUzSsUkIbQBrHTlVMx81BQLxQd9vOzGXrUBQZPLwMWpWxyCbEsGZ ii9rO5Y+Hd9FEgt8ZMYb8u98Caug59LzCyg0Kuu3Bt/gxgJ5uq/qtfKZdcP1XUUL0C m6Nuv8MAdZzy1bnUI7N01gF9KOc6L0LquCXAp2YE= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id E69CED7884 for ; Sat, 24 Feb 2024 16:40:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1708789200; bh=tnjzZMfgC+jzidF82t/9TfDpvvjCqAeCWQQZycOvZQw=; h=Date:Subject:To:References:From:In-Reply-To; b=LUbDcgML/C2NisFfNugYG9JZEcfXecgCcCb6VVGh26IuYswpEJxAlSdZtNts+B8IC GCZkf9ZF6r+fGRahJAg7HkefYF5OY4EJ/fS/i+0Ir9LCNXudhnD1GZrQY0cKnE546s cf064S8rd99ypPCcag6G8bnvkpRmyVHbHPHDHrTY= Message-ID: <2421f1a5-d924-4912-abff-e000e41f5459@quip.cz> Date: Sat, 24 Feb 2024 16:40:00 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: gpart device permissions security hole (/dev/geom.ctl) To: stable@freebsd.org References: Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=G@elsa.codelab.cz]; R_DKIM_ALLOW(-0.20)[quip.cz:s=private]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[quip.cz]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=G@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TAGGED_FROM(0.00)[MS=KB=quip.cz=000.fbsd]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[quip.cz:+] X-Rspamd-Queue-Id: 4Thrfy6wd5z4Qt5 On 22/02/2024 22:23, Vincent Stemen wrote: > 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. I agree with this security problem. Just a small note - there are backups of partitions (/var/backups/gpart.*) created by periodic script /etc/periodic/daily/221.backup-gpart (if you have daily_backup_gpart_enable="YES" in your /etc/periodic.conf or in a /etc/defaults/periodic.conf which is the default). That way you can get back the number plate on you house in some cases. Kind regards Miroslav Lachman