[pid 3844872] stat("/proc/1", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 3844872] openat(AT_FDCWD, "/proc/1/stat", O_RDONLY) = 4
[pid 3844872] openat(AT_FDCWD, "/proc/1/cmdline", O_RDONLY) = 4
[pid 3844872] readlink("/proc/1/exe", 0x20c0520, 1024) = -1 EACCES (Permission denied)
[pid 3844872] stat("/proc/2", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 3844872] openat(AT_FDCWD, "/proc/2/stat", O_RDONLY) = 4
[pid 3844872] openat(AT_FDCWD, "/proc/2/cmdline", O_RDONLY) = 4
[pid 3844872] stat("/proc/3", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 3844872] openat(AT_FDCWD, "/proc/3/stat", O_RDONLY) = 4
[pid 3844872] openat(AT_FDCWD, "/proc/3/cmdline", O_RDONLY) = 4
...
Why would it do that? Is there any way to prevent it?
We can answer part of that with just a little more reading. What's pid 3844872?
For me, the series of queries against /proc happen from a process that, just a bit earlier, called exec. So it's not really zoom reading "all processes and arguments" but ... `pidof gnome-session`, so I guess zoom is looking for the pid of gnome-session.
To what nefarious purpose zoom intends to put this knowledge of gnome-session's pid, I can't say - I am not running gnome-session so my trail goes cold; but at least for me, for that particular run, zoom itself doesn't actually see the contents of all of those files.
Another angle for Zoom to do that, is that it is a massive Chinese spyware application, which can target users by meta data or IP, like it did by messing with the calls of activists. A bit like how anti-virus companies are sometimes charged with exfiltrating secret documents.
Mounting /proc with "hidepid=2" should prevent it from seeing processes owned by other users, although it would still be able to see your processes.
Alternatively, it shouldn't be too hard to create an AppArmor profile that blocks access to /proc.
Other options might include things like SELinux, seccomp-bpf, namespaces, cgroups, etc., depending on what's available on your host.
Or you could just, you know, obliterate it from your system altogether. That's almost certainly the best option.
Use a flatpak
Hook the stat, openat, readlink functions within the zoom process, experiment with blocking (returning failure) based on arguments.
Put it into it's own namespace, and only allow it to connect to your X11 session over TCP.
Firejail[0] allows cobbling together various linux sandboxing features, including namespaces which should result in an isolated proc filesystem which doesn't see the other processes. But I don't know if the default profile for zoom does that, you have to test it or write your own.
I once worked on a file synchronization application that would scan processes when files were locked. I don't remember if we put the process name in the UI, but we logged detailed information about the other process in case someone contacted support. (Sometimes users ran weird applications that kept files locked.) I believe we had to scan through all processes and inspect their open file handles.
I would assume some things like: Maybe there are applications that are known to cause problems for Zoom? Maybe some applications lock the camera or microphone? Maybe some applications hog the CPU and cause encoder problems?
If you really want to know more, consider decompiling zoom and/or looking at strings compiled into the binary.
Zoom is probably footholding their place as to be able to inform its educator whether their students’ behavior are acceptable or are cheating.
Most probably.
But some of the info its reading seems a little bit too much
cough 'telemetry' cough
I prevent it by running Zoom in a VM on Qubes OS.
You'd have to be crazy to install Zoom given their history.
Maybe run it in a chroot?
Shoshanna Zuboff has an excellent book on "surveillance capitalism", if you want to read more on the trend.
Do what I do: Run it on a burner computer connected to your guest network.
Stop using non-free software if you're doing anything important on that machine.
This is enough for me to remove the app and just use it in the browser.
You can probably prevent it with capabilities, or selinux, or with a container. Unless you just enjoy the fashion statement of tinfoil hats, it's not worth it.
But if you really must, use the web version only.
If you can avoid it, jitsi is a great alternative. Much smoother video than teams and much lighter