Live data from Hacker News

Linux Zoom client proactively reading everything written to X11 clipboard

hachyderm.io

141–150 of 176 posts

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#141
post #105
post #97

Earlier quoted context omitted.

> They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f ... On Linux/X11 even when you run a program sandboxed or as a different user if you use a master Xserver the sandboxed program still can listen and modify all your input/output including keyboard/mouse events and window content of every application.

could xhost(1) help here?

I think the only possibility that comes to mind is creating an ebpf module that sandboxes all filesystem calls and trampolines all ld_open calls.

But then you would have to provide massive amounts of patched/"safe" variants of all kinds of shared libraries which is unfeasible.

But I mean in the xorg use case it would be possible to just provide your own library that fakes the expected returns and sends fake data to the sandboxed applications.

I did a similar thing with barrier (though using LD_PRELOAD, see [1]) on my debian system to force a different behavior.

Source: Am kind of experimenting with ebpf a lot for that use case. C ABIs and SO files are a mess though. A real messy mess.

[1] https://github.com/cookiengineer/barrier-disable-dpms

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#142
post #60

with Wayland it's generally not any safer. if you use Wayland's security context to prohibit privileged protocols such as arbitrary clipboard access then an application will either not be able to grab clipboard content until you focus on it or the attempt will be noticeable as it spawns a short lived window in an attempt to grab focus.

Apps generally need not get clipboard contents unless focused on right? Like this should be the default in my view and kinda disappointed it isn't for Wayland.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#143
post #134

Earlier quoted context omitted.

Snaps are a lot lot better in this regard especially in the perspective of connections. You can define connections to home, camera, network etc... I have not seen the same in flatpak.

Sure flatpak have a static permission system too, even it is not recommended and xdg portals are the way of integrating with a host. https://flathub.org/en/apps/com.github.tchx84.Flatseal

I don't get why a big company like Zoom, with presumably lots of users who are on Linux, only gives us a .rpm/.deb instead of a Snap/Flatpak. Seems like doing the minimum.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#144
post #123

I wish most Linux distributions had something like a standardized permission manager in which you enable the single policies apps are running with, similarly to what happens in Android (that has some Linux stuff under the hood). How hard would it be to have something like this? And I can’t even imagine the difficulty of gathering together the whole community around this standard...

> similarly to what happens in Android Do you wish to give this app access to _all_ your {files, photos, phone calls, messages} ? /s What do we need permissions for, then ? Let MS-DOS come back.

Actually we should have something like iOS in which you can allow an app to access certain images (or whatever), or manage the images it generates.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#145

Earlier quoted context omitted.

Not parent, but the web player used to be a down-graded experience from the native app. If you need Zoom for a professional setting, those functions could be important. Do not know if this is still true, but at one point, the web player would only let you see one speaker at a time, while the app would show multiple people at once.

I've been using the web client for over a year and that hasn't been the case the whole time, gallery view is an option.

Well this was back in COVID, sometime fresh after the always-open-port news had surfaced. Can easily believe the experience has been improved since then.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#146
post #30

Earlier quoted context omitted.

I dumped it after realizing Xen does its damndest in preventing you from hiding VM attributes from Guest OSes. Proxmox uses KVM, and is easy to configure a VM to make the guest think it's on bare metal. In the proprietary software space, a LOT of things run badly or refuse to run, or license stupidity with a guest OS. So for me, spoofing bare metal is an essential part of running ilk like Windows and proprietary apps…

Doesn't that preclude paravirtualization drivers? Seems like a major tradeoff for daily driver desktop stuff.

Xen prevents modifying ACPI data.

It also passes obvious "Xen emulated drive", and similar for all hardware interfaces.

Passes CPUID.

Can't stop any of this with Qubes/Xen. But is trivial with Proxmox/KVM.

Honestly, I wish there was a Qubes/KVM variant. It would fix every complaint, and enable running potentially malicious software (MS windows) and lie to it regarding hardware interfaces.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#147

Just run these things in your browser. Despite the dark design patterns that try to trick you into installing their desktop client, the web-based versions are fine.

not if you have to host meetings! the web versions are feature incomplete and don't support something as simple as screensharing with your camera overlayed in a corner (essential for recorded meetings).

the zoom linux client consistiently locks up my entire computer whenever i copy from the chat. ridiculous.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#148
post #6

Not the first time Zoom abuses privilege. A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end. They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f... I always ask (1) why does an app require installation and (2) why would it require root? There are valid answers for both, but realistic…

Wow thanks for the link. I have zoom on my personal laptop which isnt ideal. I always wanted to run it sandboxed

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#149
post #99

Earlier quoted context omitted.

I notice the browser version is a little resource intensive. I use it on freebsd and I need to renice the browser to -10 for it to be somewhat stable. (This is an improvement because I remember 6 years ago it didn't work on freebsd.) I ran it on a Mac last week and it spun the fan more than I'd expect.

Last time I looked at their web client, it was indeed doing absurd things (I think it used TCP and web sockets to carry video instead of WebRTC and shipped a WASM video codec that obviously can’t be GPU/hardware accelerated). Not sure if that’s malice (to nudge people towards using their invasive desktop app) or incompetence.

That explains a lot. I would guess incompetence.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#150

Earlier quoted context omitted.

Sure flatpak have a static permission system too, even it is not recommended and xdg portals are the way of integrating with a host. https://flathub.org/en/apps/com.github.tchx84.Flatseal

I don't get why a big company like Zoom, with presumably lots of users who are on Linux, only gives us a .rpm/.deb instead of a Snap/Flatpak. Seems like doing the minimum.

Snaps is a sure-fire way to only get used on Ubuntu. So that would be worse than distributing .rpm/.deb.
Post reply on HN