From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27674 invoked from network); 24 Feb 2021 20:26:28 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2021 20:26:28 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id C8FEA9C73E; Thu, 25 Feb 2021 06:26:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3EF3D9C6CE; Thu, 25 Feb 2021 06:26:01 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 1132C9C6CE; Thu, 25 Feb 2021 06:25:58 +1000 (AEST) Received: from minun.buric.co (minun.buric.co [51.15.8.196]) by minnie.tuhs.org (Postfix) with ESMTP id 79A4E9BA4D for ; Thu, 25 Feb 2021 06:25:57 +1000 (AEST) Received: by minun.buric.co (Postfix, from userid 1000) id 147DC35C0C22; Wed, 24 Feb 2021 21:25:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by minun.buric.co (Postfix) with ESMTP id F15D235C0B37; Wed, 24 Feb 2021 15:25:52 -0500 (EST) Date: Wed, 24 Feb 2021 15:25:52 -0500 (EST) From: Steve Nickolas X-X-Sender: mary@sd-119843.dedibox.fr To: Theodore Ts'o In-Reply-To: Message-ID: References: <78fede43-bf9b-5a56-5e59-e6ee5a0ee23d@spamtrap.tnetconsulting.net> <3d2d7b46-41e8-92d7-3a7b-d0f3006bc761@spamtrap.tnetconsulting.net> <3e41de9a-aaa3-0501-12e4-a99b589192f4@spamtrap.tnetconsulting.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [TUHS] /usr separation X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org, Grant Taylor Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Wed, 24 Feb 2021, Theodore Ts'o wrote: > On Wed, Feb 24, 2021 at 10:50:03AM -0700, Grant Taylor via TUHS wrote: >> Being a fan of the golden rule, I would not make, much less use, that >> derivation. I think it completely changes the meaning of the spirit behind >> the golden rule. > > Oh, sure. I agree completely that it's 180 degrees from the original > golden rule; it had intended to be a joke. Unfortunately, years of > living in a country whre the ones with the Gold really do make all of > the Rules has gotten me to the point where if I don't laugh at it, I > would have to cry.... I first heard this form used in the movie "Aladdin" (the 1992 Disney one, with Robin Williams). >> I seem to recall hearing about a problem where a rogue rm could accidentally >> wipe out part of the UEFI. Maybe it was the contents of the /boot/efi >> partition. So, I'd suggest a happy medium of mounting it Read-Only. That >> way it's known to be used /and/ it's protected from a simple rogue rm. It >> can relatively easily be re-mounted as Read-Write when necessary. As well >> as subsequently re-mounted back to Read-Only. > As far as making a system more robust against rogue rm's, I really > like scheme used by ChromeOS, where the entire file system is not only > read-only, but protected by a cryptographic Merkle Tree such that if > malware attempts to modify it, the system will crash. This is > combined with firmware which will only load a kernel with a valid > digital signature, and the user data is stored on an encrypted file > system mounted on /mnt/stateful_partition and it is the only file > system mounted read/write on a ChromeOS system. It violates a lot of > expectations about where files should live on a "normal" Unix or Linux > system, but it's defnitely way more safe and secure. It may not be as much of a protection, but I replaced the system rm on my Debian with one based on 4.4BSD (since I already had the code lying around) to which I added a bit of protection against attempts to "rm -rf /" after a worm got in and ran an obfuscated version of that...thankfully it didn't run as the superuser. I do get occasional "invalid switch" errors from it while using apt, so it probably uses a gnuism (since afaict, the code I used was strictly conformant to Posix). Otherwise, it hasn't caused any issues. -uso.