The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Steve Nickolas <usotsuki@buric.co>
Cc: tuhs@minnie.tuhs.org, Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: [TUHS] /usr separation
Date: Wed, 24 Feb 2021 23:08:36 +0100	[thread overview]
Message-ID: <20210224220836.IpoLL%steffen@sdaoden.eu> (raw)
In-Reply-To: <alpine.DEB.2.21.2102241520550.15020@sd-119843.dedibox.fr>

Steve Nickolas wrote in
 <alpine.DEB.2.21.2102241520550.15020@sd-119843.dedibox.fr>:
 |On Wed, 24 Feb 2021, Theodore Ts'o wrote:
 ...
 |> 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.

Just this week i finished my move from BSD compatibility to plain
Linux-only (which you seem to run) for my "web" and my "web with
credentials" user accounts; the accounts are gone now, instead
i as "i" execute according overlays.  pstree for example now say

  [sudo..]
  box-browse.sh---box-browse.sh---unshare---
    su---.box-browse-gui-+-firefox-bin-+-Web Content

when i browse totally boxed and unprivileged.  (Still not CPU and
memory restricted, but other than that.)
The / root is the low level of an overlayfs, the upper level is
a tmpfs that may not use more than 5 percent of RAM.  It has its
own minimal /dev (with audio even) and has read/write access to
one shared folder.  Ditto with credentials, but that runs in the
global network namespace, whereas the unprivileged even runs
isolated from that.

It is a bit messy if you want to be portable to Linux
distributions which use busybox unshare etc., because there you
need to use chroot(1) yourself, and therefore mount /proc also
yourself thereafter (ie unshare(1)s --mount-proc is effectively
useless).  Also it would be nice to be able to execute a few
commands before you switch aka map user and group IDs in the
containment (if you do so).  But for open source software the
answer there usually is "shut up and hack", thus.

Of course with this approach the containers need to live in the
same X11 session, therefore the one mounts only /tmp/.X11-unix (it
is tremendous that Linux can "mount" a normal directory now!), the
other just the plain /tmp.

So an rm -f could destroy the shared folder (it lives on
a filesystem with snapshot support though).  For the credential
account it could even wipe /tmp/ and the --bind mounted .mozilla
encfs that is in the containment there (but ditto, plus specific
backups).  I have not looked at overlayfs code, but i think the
whiteouts of the upper layer will be saved in the "work" layer, so
an rm -rf / could possibly even not finish because 5 percent RAM
could exceed earlier?  Happy to (un)share ~150 lines sh(1) script.

Yes Mr. Cole, thanks for this working on overlay (less so union)
filesystems, it is tremendous!

(P.S.: that .box-browse-gui.sh is a condome to prevent that
firefox-bin as compiled by Mozilla locks me out of the system.
Have seen this twice already when browsing serious German and
Austrian magazines, needing a reboot.  So i now have my browser
session been protected by a shell guard, and my window manager
menu has a "TOUCH" entry.  If the timestamp of the touch file
becomes older than 300 seconds i hear the first gong of Big Ben
and need to touch .. after the fifth a "kill -TERM -1" happens.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  reply	other threads:[~2021-02-24 22:09 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
2021-02-24 22:08                       ` Steffen Nurpmeso [this message]
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=20210224220836.IpoLL%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    --cc=gtaylor@tnetconsulting.net \
    --cc=tuhs@minnie.tuhs.org \
    --cc=usotsuki@buric.co \
    /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).