Closed technobaboo closed 11 months ago
Hi @technobaboo.
The sandbox would need to allow just the Wayland protocols the user wants to allow.
But I leave the whole sandboxing approach to others as I don't really believe it is useful. The most effective attacks are based on social engineering, and no sandbox can prevent from that. So, the best policy is to only ever run applications from authors you trust.
so the readme basically says that if you want to have security just slap apps into a sandbox...
That basically means: This project is about making things work by default, other projects can think about making things (selectively) not work (for security purposes).
As of today, I think that Wayland is so "secure" that I basically don't want to use it. With this project, maybe we can make Wayland work (by default), and treat the sandboxed stuff as an exception (for those who really need it, e.g., because they want to run untrusted applications - something I wouldn't recommend to do).
Someone over at Reddit said it much better than I ever could:
A big problem for me is that wayland promotes a vision of computing that is basically a hellscape. Wayland supports apps that are basically untrustworthy. Apps can talk to wayland, but not too much to each others, certainly not in ways not envisioned by wayland. The desktop is a huge melee of backstabbing bastards, each shovelling as much user data as possible to their vendor.
The X view of the world is one of trustworthy cooperation. A bit naive, a festival for crapware, but also a way to unlock unexpected possibilities.
I'd rather see a cooperative, creative future where bad apples are weeded out by social mechanisms, even if it means an occasional malware victim. But understandably the IBMs of this world would rather see rows and rows of easily swappable locked down minions for their workstations, and they are the ones paying.
I fear the bureaucratic stagnation that will unavoidably follow from wayland as it is now.
Source: https://news.ycombinator.com/item?id=38780659
The X11/Wayland "security" discussions need to be looked at in a broader sense, beginning with the basic assumptions the the system is built on.
Interesting that while X11 is "a festival for crapware", "social mechanisms" pretty much have made this a non-issue on free and open source desktops.
Based on evidence, the locked down (but monetized) platforms (like Android) seem to be more a "festival for crapware" in reality.
so the readme basically says that if you want to have security just slap apps into a sandbox... but you can already do that with X apps and I can still keylog and kill apps outside the sandbox from inside and nobody's been able to stop that from happening
the reason is that the protocol itself is a security hole, so if you want to not replicate those security holes there's several options:
proxy service to just block certain API calls congrats you just made portals, ones that don't indicate to apps that their request might fail due to security meaning the app is likely to crash (because unless explicitly told to handle errors most apps just assume everything is fine)
permissions system inside the protocols while this is a bit better, you're still shoving the exact same file descriptors over wayland that portals do... d-bus is nowhere near perfect but making a second half-baked solution seems a bit overkill to me (and now since the wayland compositor itself has to handle those permissions you've added a few hundred more lines to the library used or the compositor itself with the options for customizability being hardcoded or using a complicated plugin system, or abandoning the whole compositor and breaking the user's workflow)
open a virtual port (not network) for data to come through this is basically just pipewire, and while i personally think this is a much better way to go about permissions (instead of asking "do i allow this data to come through" it's a question of "what do i give this app")... you will end up making basically another pipewire. And believe me, I've tried to write pipewire and failed a LOT, because it is absolutely obtuse... but making another one you'll have the same amount of complexity, just shifted somewhere else. someone should just make an API around the pipewire nodegraph so we can just go "gimme dmabuf of this pipewire node i got from this random app" instead of hooking it up to gstreamer :/
option 1 is the easiest to implement, 2 is the most robust, and 3 is the most flexible... but i can't see any other way to ensure security