[sf-lug] Sandboxing Zoom (etc.)

[Michael Paoli]

> From: "Akkana Peck" <akkana at shallowsky.com>
> Subject: [sf-lug] Sandboxing Zoom
> Date: Tue, 26 May 2020 14:15:09 -0600

> It's great to have the option of all these virtual meetings
> everybody's running now ... but I'm unhappy about needing to
> install proprietary binaries like Zoom and Discord on my system.
> I'd like to find a way of sandboxing them.
> Are any of you sandboxing those untrusted proprietary apps?
> How do you do it?

One can run Zoom strictly in browser, no plugins on the like needed.
Some(/many?) computer-based conferencing systems do, or allow, likewise.

If I recall correctly, between Chromium and Firefox, only one of the two
came up, with Zoom, showing me the link to alternatively run it (strictly)
in browser, without (default) of it wanting to download and use some
plugin.  And, interestingly, when I copied that in-browser only (no-plugin)
link from the browser where it was offered, to the one where it wasn't,
I was then able to also run it totally in-browser on the other browser too.

Not familiar with firejail.  There is, "of course", chroot,
BSD(-style) jail (chroot + yet more security)
Docker (essentially chroot + more security limitations),
and then there's (para-, and full) virtualization.

> I found something called firejail that sounded perfect. From the
> description, it seemed to be sort of an easy chroot (that can also
> wall off networking, devices, system calls and other services).
> Sounded perfect! After a bit of fiddling with it, I had
>     firejail --private /path/to/sandbox zoom
> running fine ... but then when I called up Settings to adjust where
> recordings were stored, it still had full access to my homedir.

Yeah, still having access to HOME outside of the chroot/jail
sounds like an issue - shouldn't (generally) be the case.

And one thing many folks far too often get wrong.
chroot and the like were *never* intended to secure processes
running as root (superuser, UID 0).  There are far too many ways
UID 0 can relatively easily punch out of chroot restrictions
(just think of all the system calls root can do that other IDs can't).
Quite the same applies to jail and Docker - don't use it expecting
it to contain root.  Egad, I've seen even large infrastructures with
huge Docker deployments ... with ... egad, stuff running as root in
all or most all the Docker containers ... security, what security,
you're nor running Docker like that for security are you?  Egad.
And don't forget about SUID ... if something throws (way) too much
stuff under chroot, including SUID root stuff ... that could open up
security issues (but (slightly?) less (or about same?) of a risk for
same outside of the chroot).

Virtualization is the only way to isolate root - if one needs be running
stuff as root.  And even there, sometimes things go wrong (but not as
commonly/frequently in the earlier days of many of the particular
respective virtualizations).  And various "full" virtualizations
generally (slightly?) more secure than para-virtualization.
Hardware virtualization support generally gains one much performance,
but possibly(/sometimes?) at (slight?) additional security risk.
Virtualization isn't as secure as a fully separate physical host,
but ... about as close as one can get short of that.

> It wasn't in a chroot jail at all. (This may be specific to zoom:
> I tried it with a couple other apps and they only saw the sandbox.
> Maybe child processes aren't jailed?)
>
> So I set up an Ubuntu install inside virtualbox, and installed Zoom
> there. That sorta works ... but the CPU load is ridiculous (this on
> my fancy new Carbon X1 gen 7, I don't even want to think what it
> would have been on my older machines), the fan is blasting at full
> speed, everything is super laggy, and I get occasional warnings
> that the high CPU use is causing a poor zoom experience (no kidding).
> Zoom by itself, outside of virtualbox, doesn't use anywhere near
> that kind of CPU load and has much better performance.
>
> Would kvm/qemu be less CPU hungry than virtualbox? Or should I be
> looking at Docker? I've never tried Docker ... would it give me a more
> effective sandbox than firejail? I've been avoiding it because when
> I google, I find tons of "here's a pre-made Docker image for you"
> and hardly any "here's how to set up your own Docker image".

I wouldn't expect qemu-kvy to be much different regarding CPU compared
to VirtualBox - their reasonably competitive software projects and I
wouldn't expect a huge difference on that - maybe not even so much as
any difference on CPU.

> Any other good sandboxing options?

Not that I can think of off-hand.  Some browsers/languages have some
sandboxing capabilities.  Other than that, I think we've mentioned
most of the means of sandboxing available on/for Linux platforms,
and even among those, some of them mostly just build upon lower-level
technologies (e.g. Docker - not exactly fundamentally new, mostly just
conveniently bundles management of chroot and other useful and security
useful stuff to go along with that).

Oh, ... apparmor and/or SE Linux could be useful.  Those could be used
to limit capabilities of an application or ID.

>         ...Akkana