3 ms·
The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each esse
by ApolloFortyNine 3y ago
The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data.
Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do.
- simiones 3y ago> The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data. Oh, yes, it's very likely that Wayland will end up with the exact same vulnerabilities. It's very hard in fact to design a windowing system that allows rich interaction between apps, but still maintains per user access control (never mind actually implementing it).
- nolist_policy 3y ago> Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do. No, the attack angle is either a untrusted app running in a sandbox (fatpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited, any apps handling foreign data is suspect here (Web browser, mail client, pdf, office suite, etc.). [1] https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurchetansingh@chromium.org/ https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurc...
- aidenn0 3y agoEverybody who uses web video conferencing will give their web-browser permission to record the screen. This already takes a huge chunk out of the security advantages. The advantage is not zero, but it doesn't seem to be as big of a win as one might want.
- danShumway 3y ago> but it doesn't seem to be as big of a win as one might want. That's a huge win. Firefox is a mainstream product with a ton of attention. And I get it from upstream repositories, it's not something I'm compiling myself. If I can get away with giving 2-3 apps total on my computer screen recording permissions (OBS, Firefox, maybe a screenshot tool or an accessibility client), that is a massive reduction in attack surface, that would be a very large security win. It would be great if the primary attack vector for recording my screen was an application with decades of sandboxing efforts going into preventing untrusted code from doing things like recording my screen without my knowledge.
- aidenn0 3y agoFirefox contains essentially 99+% of the untrusted application code I run, and I suspect this (or Chromium) is the case for many others too.
- danShumway 3y agoGreat! Firefox is also the app on my computer that does by-far the best job sandboxing untrusted code. It's good for us to be running most of our untrusted code in that environment, and even better for us to be blocking untrusted operations outside of that environment. I genuinely don't understand the issue, it's a big security win if I can close off permissions on my system and have them open just for the apps that have good sandboxing around their untrusted code. Bonus points if the app in question allows per-domain screen recording permissions, which Firefox does. I would go so far as to say that (one of) the reasons you run 99+% of your untrusted application code in Firefox is probably because Firefox is one of the very few places on your computer where it's safe to run that code. So it's a big win if we can start pulling some of those same sandboxing ideas into the native world; maybe that makes it easier to use more native apps for some tasks. It's a big win if I can treat apps on my computer the same way that I treat a random website. Also keep in mind that "untrusted" is not a binary state. I pretty much only run apps on my computer that I "trust", but do they need to be able to record my screen? No, and I love the possibility of not needing to worry quite as much about what happens if they get compromised. ---- There's a somewhat strange notion here that because people do everything in the browser per-app privileges don't matter. But in fact, the reason the browser's security model works and the desktop's doesn't is because the browser has per-domain privileges and permissions, and it's not that per-app permissions don't matter, it's that they do matter and the lack of them is why we centralize untrusted code into one of the few apps on our computers that has per-"app" permissions. Browser permissions work because they are granular, you can grant Zoom access to record your desktop without granting access to Facebook. So maybe if the desktop copies that, maybe far in the future you won't need to run everything in your web browser just to feel secure. But as it stands with X11 I feel a lot more comfortable using a browser to record my screen specifically because it has privileges and permissions around that are segmented per-domain/"app". The lack of sensible security controls on the desktop is a contributing factor to why people don't use the desktop, and being able to lock that in and restrict the scope of where screen recording can happen does make me feel a lot more secure about my desktop.
- danShumway 3y ago> No, the attack angle is either a untrusted app running in a sandbox (f[l]atpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited Agreed. This debate is particularly frustrating because X11 vulnerabilities get brought up as an excuse for ignoring other sandboxing efforts, and then Wayland gets dismissed because of vulnerabilities when not using other sandboxing methods. You can't win! ---- Even if I'm giving my web browser full access to my computer, there are apps I want to sandbox without running them in a full VM. And there are multiple parts to this puzzle to get better security and sandboxing, but those sandboxing efforts don't work if I can't secure the most basic parts of the visual desktop. If someone is demanding perfect sandboxing before we start looking at X11, they're going to be waiting a long time because there is a limit to how much progress we can make in this area while X11 stays dominant. And okay, sure, we're setting up clipboard access for web browsers, but I can turn that off. And then I can take advantage of flatpak, snap, qemu, whatever and I can at least get closer to actual sandboxing controls, even for non-malicious apps. And I can do partial sandboxing, which is also a good thing -- the idea that everything needs to be either fully separated from each other or have full permissions is just not a good approach to security, sometimes we partially trust things. ---- Linux security is like we're in a boat with multiple holes that are taking in water, and whenever anybody tries to plug one of the holes, critics jump out and say, "what's the point, if someone can execute apps on your machine, there's plenty of other nasty things they could do." And so you move to the other hole and somebody says, "what's the point, attackers can just record your desktop." There are multiple holes on the ship, let's start patching them. Getting better sandboxing controls into Linux is something that is going to take time and that means we're going to be patching holes while other holes exist that we haven't gotten around to yet. There is a limit to what tools like Bubblewrap can do for a graphical app if it's hooked up to X11. And yeah, I want clipboard controls for my web browser, but also I run more apps on my computer than just a web browser, and different apps have different problems. It's not even just about exploits or malicious apps entirely, sandboxing is useful even just for setting up temporary builds or dealing with buggy code and the fact that we don't have perfect solutions shouldn't be an excuse to not improve the situation at all.