[TUHS] /usr separation

[Theodore Ts'o]

On Wed, Feb 24, 2021 at 10:50:03AM -0700, Grant Taylor via TUHS wrote:
> > I would call this the "Tyrany of Gold", as in the reformulated Golden
> > Rule, "The ones with the Gold, makes the Rules".
> 
> 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 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.

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.)  Fortunately, if you have a rescue CD / USB Thumb
drive, it's relatively easy to recover from this.

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.

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 feel like we've already abandoned i386 as in 80386 (or compatible)
> architecture.  I think we now require Pentium (586?) or better.  At some
> point, we'll completely remove 32-bit support from mainstream Linux
> distributions, thus requiring something from the 21st century.

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

						- Ted