What is the best way to run zoom in a jail?

An organization I belong to is using zoom for online classes. There are significant issues using zoom from a browser, and zoom is trying to pressure everybody to install their application. I don’t trust them, and am unwilling to expose my data to potential spyware. What is the easiest way to run the zoom application in a jail? I’d prefer not having to create a virtual machine just for zoom, since my laptops don’t have all that much disk space and my big machine isn’t usually booted into Linux.

A virtual machine would probably be safest, though the most heavy solution. Pro point is that virtual machines are common and well documented. And one can place the image on an external ssd.

There are Dockerfiles for zoom on the net but running desktop apps through a container engine is cumbersome and requires at least some understanding of how containers work.

Next up is sandboxing via flatpak. Never tried this but there is a package listed on flathub.

On the other hand, the easiest way would probably be reviving one of the half dozen old Android phones or tablets, reset that to factory defaults, connect a throwaway google account, and install the Android app. That’s what I would do.

I suggest a look at firejail. You can install it from the openSUSE repositories (at least for Tumbleweed), and it will create default configurations for many popular applications in /etc/firejail , zoom included.

Running firejail zoom from the command line brought it right up.

Please note that I’ve only toyed with zoom thus far, haven’t done anything serious with it. I don’t know if I’ll have to tinker with configuration settings in /etc/firejail/zoom.profile.

Good luck!

  1. Create a new user group and user for your Zoom sessions – this user only uses Zoom – the user doesn’t have any of your personal details.
  2. The new user group doesn’t have access to any other user groups – also, the GID is something near the top end of the GID number range – ditto the new user’s UID.
  3. The new user’s home directory is not in the ‘/home/’ directory – create a new pseudo user for the new User Group (“Zoom
    ” users … ), who’s “home” directory is ‘/home/«new user group»/’. 1. The new user’s home directory is below ‘/home/«new user group»/’.
  4. Do the same thing for all existing users – create a new pseudo user within the “users” group who owns ‘/home/Users/’.
  5. Move the home directories of the existing users to ‘/home/Users/’ – one directory level down from ‘/home/’ …
  6. Remove the “other” access – “world” access – from the directory ‘/home/Users/’.
  7. On your private WLAN (WiFi), set up “guest” access on the router – assuming that the router supports this feature and, allow the “Zoom” user to only use that “guest” WLAN.

The “Zoom” user will not have access to your LAN and everything that’s connected to that LAN …
The “Zoom” user will not be able to access any of the “normal” user files on your system …
The “Zoom” user will not, via “Zoom”, be able to “sniff around” – neither on your machine nor, on your LAN … >:)

firejail” is available from the standard repositories for Leap 15.2 and, from the “Virtualization” repositories for Leap 15.1.
[HR][/HR]Yes, the sandbox functionality offered by “firejail” essentially offers a similar amount of security to my solution, with the difference that, regardless of any group memberships the concerned user may have, the sandbox protects the system directories:

  1. Only a few files in the user’s home directory are accessible to the application being run in the sandbox – for example, taking the case of Firefox, only the Firefox configuration files in the ‘~/.mozilla/’ directory.
  2. System directories are handled as follows:

[INDENT=2]/boot – Blacklisted – no access.
/bin – read-only.
/etc – read-only.
/etc/passwd and /etc/group – only a reference to the user who had initiated the application’s processes.
/home – only those files of the actual user which have been defined in a “firejail” profile.
/lib, /lib32, /lib64 – read-only.
/proc, /sys – for the new PID Namespace, remounted.
/sbin – Blacklisted – no access.
/selinux – Blacklisted – no access.
/usr – read-only.
/usr/sbin – Blacklisted – no access.
/var – read-only.
The directorys /var/lock, /var/log, /var/tmp, and other directories under /var/lib and /var/cache are remounted via tmpfs.
[HR][/HR]Bottom line:

  • Less effort with respect to the user’s home directories than my solution.
  • Any system group privileges a given user may have, are revoked.

Here’s the firejail home page, in case our OP returns:


I understated in writing that the user will find “many” default configurations for popular applications. /etc/firejail includes hundreds of .profile files.

I am replying to this message in a firejail’d browser, and now run almost everything that connects to the internet through firejail, with no performance hit. I wish that I’d configured it a long time ago.

I just found out the hard way that firejail’s zoom profile is the only one that doesn’t work “out of the box.” A bug has been fixed, but the fix hasn’t made it to version 0.9.62. The Linux app loads, but isn’t usable.

You can fix it by:

  • Creating a zoom.local file in ~/.config/firejail, which will take precedence over the settings in /etc/firejail/zoom.profile

  • The contents of zoom.local should be:

protocol unix,inet,inet6,netlink
ignore seccomp
seccomp !chroot

One could imagine that, my solution is more reliable – at least for the case of “Zoom” … >:)

Based on the following info

The openSUSE section describes a very long list of dependencies which could complicate running in a chroot or firejail, which I consider an “improved” chroot.
I’d recommend running in a docker container or virtualization.

If you install virtualization like Virtualbox,
Aside from the Virtualbox app files, the vm files can have a small footprint…
If you install only an X Window system running a WM (no Desktop), your files would be maybe about 700MB or so (I haven’t checked recently) plus the zoom app and dependencies (maybe 100MB max?). Plus, you’d want to have a decent amount of RAM, maybe 4GB recommended although 2GB might work.

Alternative might be to create a Live Image with zoom on it and boot to that… Can be on a USB stick or CD.
Depending on what level of security you want, you might also simply create an alternate User account.
I don’t know what security context Zoom requires, but if it can be run in User mode, then the app will run in that User’s security context and wouldn’t access files owned by root or any other Users on the machine. Of course, if any part of Zoom has root access, then this solution doesn’t isolate very well.

My estimations,

FWIW: I just hosted a meeting in Zoom running under firejail, and everything worked (with the zoom.local file described in my earlier post). I also regularly run Skype in firejail without problems.

What I like best about running apps through firejail is that the setup is so transparent. I created a bunch of tiny shell scripts to launch, say, “firejail firefox” or “firejail zoom” instead of un-jailed firefox or zoom, and edited the desktop app icons accordingly. The desktop and menus look as they did before; I start programs as I did before, rarely notice any delay, but most everything that accesses the internet is now run through firejail. I don’t have to fire up a VM, log in as another user, even open a terminal window.

Are those “desktop app icons” located in /usr/share/applications? If that’s the case they’ll be overwritten by incoming updates, since that’s the distro zone. Also, it’s not the only way to launch apps. Instead, place these shell scripts in a directory looked up sooner in the search path, e.g. $HOME/bin, /usr/local/bin. Then confirm running which firefox on a terminal.

The good thing about firejail is that it adds profiles for many popular programs, yet obviously it just can’t cover all available programs. The issue is that firejail being a suid program, i.e. it runs as root even without sudo, a malicious program can use it as a privilege escalation path.

So if I can avoid a suid program on my system, for zoom I’d prefer the approach dcurtisfra outlined above, which I suppose can be used together with xdg-su to impersonate the fake user on my own user session.

Thanks for the tip re /usr/share/applications. I hadn’t thought of that.

The scripts are in /usr/local/bin. (Which, in my ignorance, is the only place I know to put them. :\ I still have a lot to learn about Linux.) I monitor what’s running with $ firejail --list or $ firejail --top. So far, no unpleasant surprises.

That’s not something I considered – I presume you mean:

 > xdg-su -u «*new isolated user name*» -c zoom

Meaning that, Zoom will be run in the new isolated user’s environment – without having to login as the “new isolated user” «which, by the way, isn’t a “fake” user» …

  • This approach offers a charming way to avoid having Zoom use the GUI of your “normal” user’s session, in a direct
    fashion – which would be the case if you executed “su -u «new isolated user name» -c zoom” …

On the other hand, if you really wanted to be certain that Zoom couldn’t access your “normal” user’s environment in anyway way at all, you would have to login to the “new isolated user’s” account …

I tested what xdg-su would leak:

$ useradd -g nogroup -M guest
$ sudo passwd guest
$ xdg-su -u guest -c "kate" &
$ sudo cat /proc/$(pidof kate)/environ | awk -v 'RS=\0' -F= '{print $0}' | sort | less

It leaked:

  • local hostname (would be leaked anyway with a regular desktop session)
  • my real user name
  • my home directory (it’s inaccessible to kate due to guest user not being in the same group)
  • my favorite editor
  • my tmux session (!)

So I redid the test with konsole to investigate further:

$ cd /home
$ xdg-su -u guest -c "konsole" &
guest:/home> tmux list-sessions 
error connecting to /run/tmux/1000/default (Permission denied)
guest:/home> sp play
/usr/local/bin/sp: line 58: /home/guest/.config/spotify/clientrc: No such file or directory
/usr/local/bin/sp: line 284: /proc/2327/environ: Permission denied
Failed to open connection to "session" message bus: Failed to connect to socket /tmp/dbus-hr0cOwt0qw: Connection refused