Re: [TUHS] /usr separation

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 3530 bytes --]

On 2/24/21 11:37 AM, Theodore Ts'o wrote:
> 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....

When colleagues would say "you would think" or "I've been thinking" or 
the likes, with "We don't do that!  The logo does it for us!" when 
dealing with IBM shenanigans.  Again, laugh, lest I cry.

> So technically it doesn't wipe out UEFI; it just will destroy the 
> ability to boot the system.  (e.g., this is where Grub lives, and if 
> you delete it, UEFI will no longer be able to launch Grub, and hence, 
> not boot Linux.)

ACK

Either way, it causes someone to have a Bad Day™.

> Fortunately, if you have a rescue CD / USB Thumb drive, it's relatively 
> easy to recover from this.

And now we're back towards the start of this (sub)thread of a system 
being able to boot strap itself or not.

> A rogue rm which deletes /bin (even if /bin is a symlink to /usr/bin, 
> all of the shell scripts and /etc/passwd entries probably still refer 
> to /bin/sh) is going to make the system similarly unbootable.

Agreed.

Though I think there is a difference in containing the damage to the OS 
vs going beyond it and damaging the firmware configuration.

> 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.

I've not looked at Chrome OS or how it does things because of my dislike 
for actually /using/ it.  However, it sounds like it's worth popping the 
hood and looking at things.

> For now, as far as I know, Debian still supports a 486 (or i386 with 
> an i387 co-processor, which was my first Linux system).  But yes, 
> it is very likely, absent people showing up to volunteer to support 
> 32-bit userspace at Debian (e.g., ongoing security updates, support 
> for the i386 build farm, reporting and triaging build failures of 
> packages on i386, etc.), that the i386 arch will probably get dropped 
> after Debian Bullseye release (which will probably happpen sometime 
> in mid-2021 if I had to guess).

I don't know how quickly 32-bit will disappear.  I think the embedded 
market and other non-i386 32-bit platforms will likely keep 32-bit code 
around for a while yet.  At least user space application code.  Maybe 
the i386 kernel code will languish ~> bit rot.  Or worse, get in the way 
of maintaining 64-bit code and thereby be ejected.

> I'm not sure there are any 486's around any more, and it's likely most 
> uses of systems with i386 binaries are on 64-bit processors running 
> in 32-bit mode, so 486 vs 586 is probably not all that important in 
> the grand scheme of things.

¯\_(ツ)_/¯



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]