[sf-lug] chroot(2): Re: Sandboxing Zoom (etc.)

[Michael Paoli]

> From: "Akkana Peck" <akkana at shallowsky.com>
> Subject: Re: [sf-lug] chroot(2): Re:  Sandboxing Zoom (etc.)
> Date: Fri, 12 Jun 2020 10:38:07 -0600

> Michael Paoli writes:
> [lots of great details about setting up a chroot]
> Love it, thanks! I'll save that article and go through it in detail,
> and maybe try it for Zoom.
>
>> And, ldd(1) and strace(1) come in quite handy for determining what's
>> needed and/or why it doesn't (quite) work.
>
> That got me thinking, and I wrote a little Python script to help
> with that. Give it a command, and it runs it under strace and
> gives you a sorted list of all the directories containing files
> the program opened, and the list of files from each directory.
> That, combined with the chrootbuilder script that Rick mentioned,
> might make this at least a bit easier. And it's kind of fun to
> run in general, to see what files are being opened.
>
> https://github.com/akkana/scripts/blob/master/dirsneeded.py

Cool.  Could even potentially build upon that with additional
programs/programming and/or options.  E.g.:

o provide a test / regression test framework for what's to be chrooted,
   so utility/program can make pass/fail determination if all that's
   needed in the chroot is present or not.
o be able to logically combine and test a set of components, to
   determine what's required for the full set of components to
   successfully function
o figure out bare security minimums needed, e.g.:
   o determine if any given component is actually required or not (e.g.
     divide and conquer testing - just because it's accessed doesn't
     necessarily mean it's required)
   o for anything where access attempt is made in chroot and fails,
     at least by default, only consider it something to possibly be added
     to chroot if that something exists outside the chroot
   o for all opens and the like, track if it's opened for read, or
     write/append, or both, and furthermore also track if it's only
     read, or only written / appended to
   o track directories accessed, and if merely accessed, or if also
     read.  Likewise, divide and conquer, do any tests fail if read
     access is removed, likewise to then have x removed, or directory
     removed.
   o have intelligent logic to figure out more complex bits, e.g.
     nsswitch.conf may have multiple methods configured to handle
     something, figure out which method(s) are actually needed in
     chroot.  Likewise for something like that, eliminate all the
     bits that are unneeded/irrelevant (e.g. components not used/needed
     in chroot).

Maybe out there somewhere, there's already software that handles much or
all of this?

Could also have option to, rather than go for tightest security, go for
"most like non-chroot" - bringing into chroot all it tries to access
that exists outside chroot - and with all the same ownerships,
permissions, etc., and not trying to minimize stuff in, e.g.
nsswitch.conf, passwd, group, etc.  That could be potential
build/configure chroot for different purpose not intent on
security hardening ... or security-wise, could be for more
accurate emulation and for then security testing within the chroot.