by neolog on 8/17/21, 6:38 PM with 263 comments
[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?by reilly3000 on 8/17/21, 9:25 PM
by dllthomas on 8/17/21, 10:45 PM
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.
by xfitm3 on 8/17/21, 11:38 PM
by vishho on 8/18/21, 12:52 AM
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.
by dmart on 8/17/21, 11:28 PM
by jlgaddis on 8/17/21, 9:36 PM
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.
by noobermin on 8/18/21, 5:36 AM
by wins32767 on 8/17/21, 8:45 PM
by laurensr on 8/17/21, 8:46 PM
by luke2m on 8/17/21, 8:49 PM
Use a flatpak
by jagged-chisel on 8/17/21, 9:08 PM
Hook the stat, openat, readlink functions within the zoom process, experiment with blocking (returning failure) based on arguments.
by nullc on 8/18/21, 5:34 AM
by akira2501 on 8/17/21, 8:48 PM
Put it into it's own namespace, and only allow it to connect to your X11 session over TCP.
by the8472 on 8/17/21, 9:53 PM
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.
by tryauuum on 8/17/21, 8:46 PM
by gwbas1c on 8/18/21, 2:23 AM
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.
by egberts on 8/18/21, 11:39 AM
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.
by mcrmonkey on 8/17/21, 11:51 PM
But some of the info its reading seems a little bit too much
cough 'telemetry' cough
by amelius on 8/17/21, 10:27 PM
by fsflover on 8/17/21, 9:30 PM
I prevent it by running Zoom in a VM on Qubes OS.
by sneak on 8/17/21, 11:58 PM
You'd have to be crazy to install Zoom given their history.
by MattGaiser on 8/17/21, 9:10 PM
by ayush--s on 8/18/21, 2:28 PM
by phendrenad2 on 8/17/21, 8:57 PM
Maybe run it in a chroot?
by andrewlevi on 8/17/21, 9:57 PM
by kevmo on 8/17/21, 10:06 PM
Shoshanna Zuboff has an excellent book on "surveillance capitalism", if you want to read more on the trend.
by MichaelGroves on 8/17/21, 9:34 PM
Do what I do: Run it on a burner computer connected to your guest network.
by swiley on 8/18/21, 8:16 AM
Stop using non-free software if you're doing anything important on that machine.
by ianlevesque on 8/17/21, 8:43 PM
by 99mans on 8/17/21, 10:01 PM
by aFaid7see0ni on 8/17/21, 11:03 PM
by gigatexal on 8/17/21, 6:45 PM
This is enough for me to remove the app and just use it in the browser.
by 0xbadcafebee on 8/17/21, 11:55 PM
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.
by GekkePrutser on 8/17/21, 9:58 PM
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