The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steve Nickolas <usotsuki@buric.co>
To: Theodore Ts'o <tytso@mit.edu>
Cc: tuhs@minnie.tuhs.org, Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: [TUHS] /usr separation
Date: Wed, 24 Feb 2021 15:25:52 -0500 (EST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2102241520550.15020@sd-119843.dedibox.fr> (raw)
In-Reply-To: <YDac/4mBoxRSZs2J@mit.edu>

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.

<snip>

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

  parent reply	other threads:[~2021-02-24 20:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-20 23:09 [TUHS] Abstractions M Douglas McIlroy
2021-02-21  8:15 ` Otto Moerbeek
2021-02-21 11:08 ` Rich Morin
2021-02-21 22:40 ` Dave Horsfall
2021-02-21 23:01   ` Steve Nickolas
2021-02-23  3:31     ` Andrew Warkentin
2021-02-23 17:29       ` [TUHS] /usr separation (was: Abstractions) Greg A. Woods
2021-02-23 18:28         ` [TUHS] /usr separation Grant Taylor via TUHS
2021-02-23 18:57           ` Theodore Ts'o
2021-02-23 20:29             ` Grant Taylor via TUHS
2021-02-24 14:14               ` Theodore Ts'o
2021-02-24 17:50                 ` Grant Taylor via TUHS
2021-02-24 18:37                   ` Theodore Ts'o
2021-02-24 18:48                     ` Grant Taylor via TUHS
2021-02-25  3:38                       ` Theodore Ts'o
2021-02-24 20:25                     ` Steve Nickolas [this message]
2021-02-24 22:08                       ` Steffen Nurpmeso
2021-02-24  3:12         ` [TUHS] /usr separation (was: Abstractions) Andrew Warkentin
2021-02-22  0:13   ` [TUHS] Abstractions Warren Toomey
2021-02-27  2:47     ` Dave Horsfall
2021-02-23  0:25   ` Wesley Parish
2021-02-23  0:38     ` Steve Nickolas
2021-02-23  2:50       ` Theodore Ts'o
2021-02-23  3:19         ` Warner Losh
2021-02-23  1:47     ` Theodore Ts'o
2021-02-21 22:54 ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2102241520550.15020@sd-119843.dedibox.fr \
    --to=usotsuki@buric.co \
    --cc=gtaylor@tnetconsulting.net \
    --cc=tuhs@minnie.tuhs.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).