5 ms·

I 100% agree with the performance improvement goals, but I think the security claims are overblown, and overly cautious. I honestly don't understand the point o

by ottah 11mo ago

I 100% agree with the performance improvement goals, but I think the security claims are overblown, and overly cautious. I honestly don't understand the point of trying to implement the security boundary in the display manager. It solves one class of security issues, while breaking a lot of accessibility and automation. The display manager just shouldn't be enforcing rigid per processes security controls, that's better done further down the stack. Or at a minimum security controls should respect user freedom enough to let a user access normally restricted features, with out the all or nothing elevation to root. There's a middle ground here where we don't break the world, and they get their shiny security policies.

creatonez 11mo ago
> that's better done further down the stack If you do it further down the stack, you break accessibility and automation even more... this has been tried. Doesn't work. The end goal is to have actually working Android-like sandboxing rather than some broken firejail crap.
- ottah 11mo ago
  So we don't get the security benefits or accessibility. I'm not sure what is being solved. I'm all for a modern display system, I'm just not convinced the security claims are in anyway justified.
  - creatonez 11mo ago
    How is preventing apps from spying on each other through the display manager not justified? That's the lowest hanging fruit for desktop sandboxing.
aidenn0 11mo ago
I think The fact that people e.g. run the ydotool service as root is an example of this. It's like making a safe that is so hard to open that people just drill a hole in the bottom; you end up with something less secure than a safe that was easier to open.
estebank 11mo ago
Where in the stack should it be enforced that my cute desktop clock doesn't pull a Copilot and takes a screenshot of the entire desktop every 15 seconds to send to a remote service?
- atherton94027 11mo ago
  If your system is already running malware, why wouldn't the malware use a privilege escalation exploit (which are relatively numerous on linux) to access your data rather than some X11 flaw which depends on their code getting started by the user?
  - array_key_first 11mo ago
    Because it's not an x11 "flaw" or exploit, it's just how X works. I also just don't buy the whole "well other stuff has exploits too" mentality. I mean, yeah, it does, maybe. So why bother creating a password to a service if their database is probably running Linux anyway and the rdbms is probably compromised and yadda yadda yadda. It's the kind of argument you can make for anything. Also no - privilege escalation is not "numerous" on Linux. It's very difficult to do in practice. It's only really a problem on systems built on old kernels which refuse to update. But those will always be insecure, just like running Windows 7 will be insecure.
    - atherton94027 11mo ago
      A quick search for "linux local privilege escalation" in the CVE database (https://www.cve.org/CVERecord/SearchResults?query=linux+local+privilege+escalation https://www.cve.org/CVERecord/SearchResults?query=linux+loca...) shows 25 results just for this year, so clearly these are very common. So basically we have two issues here: 1. either focus on security even though these changes don't really improve the threat model 2. or allow disabled users and anyone who uses accessibility features to use GUIs
- ottah 11mo ago
  A security in depth approach obviously. Run less, use vetted sources, when running suspect software execute in a properly sandbox context. Seriously what's the point of securing screenshot and key loggers if a malicious process has full access to the users home directory, auido stack, webcam and network? If you can't trust the process don't run it. If you have to run it, isolate all of it. Wayland gives you neither the freedom to safely tailor your security policy, nor the security guarantees to warrant its inflexibility.
surajrmal 11mo ago
The fact that desktop Linux is all or nothing in terms of privilege escalation is a design issue, however arguably Wayland gives us the tools to be more granular. Android has a permission system that makes sense can it's display manager is definitely closer in design to Wayland than it is to x11.
- account42 11mo ago
  Android is the antithesis of an open computing platform and if anything the Linux desktop should use it as an example of what not to do.
  - surajrmal 11mo ago
    Android's sandboxing is doing work for the benefit of the user. This is similar to how your web browser sandboxes JavaScript. Not every app needs access to my location and providing it access shouldn't require root. The Linux ecosystem understands this and it's why there is a large push for sandboxing models in software such as flatpak. Even if you disagree with Android at some level it hard to argue that users benefit from being able to control what the software they run is capable of doing. Otherwise we wouldn't have filesystem permissions to begin with, in the name of "freedom".
    - amlib 11mo ago
      But them it's a question about how trustworthy an app is. Wouldn't it be better for software installed from your own distro repository to be fully trusted and require few or no security popups? After all, they are vetted to a much, much higher standard than any app store. Meanwhile flatpak apps and a random binary you've donwload get the full security isolation, because you can't trust third party devs.
      - surajrmal 11mo ago
        That's not a scalable solution as not every piece of software can pay the packaging cost for every Linux distro. Maybe it's fine for core system software, but it's too difficult to expect that model to work for all software. Imagine if every website you interacted with needed to ship new website updates by packaging it and getting it vetted. I think you still need a centralized distribution model even for things like flatpak to ensure some level of centralized auditing and revocation for software that has access to sensitive capabilities. However this doesn't necessarily need to be as large of a barrier for shipping updates as trying to package your software for a distro (and playing the game of trying to get your shared library versions aligned).

by ottah 11mo ago

creatonez 11mo ago

> that's better done further down the stack If you do it further down the stack, you break accessibility and automation even more... this has been tried. Doesn't work. The end goal is to have actually working Android-like sandboxing rather than some broken firejail crap.

ottah 11mo ago
So we don't get the security benefits or accessibility. I'm not sure what is being solved. I'm all for a modern display system, I'm just not convinced the security claims are in anyway justified.
- creatonez 11mo ago
  How is preventing apps from spying on each other through the display manager not justified? That's the lowest hanging fruit for desktop sandboxing.

aidenn0 11mo ago

I think The fact that people e.g. run the ydotool service as root is an example of this. It's like making a safe that is so hard to open that people just drill a hole in the bottom; you end up with something less secure than a safe that was easier to open.

estebank 11mo ago

Where in the stack should it be enforced that my cute desktop clock doesn't pull a Copilot and takes a screenshot of the entire desktop every 15 seconds to send to a remote service?

atherton94027 11mo ago
If your system is already running malware, why wouldn't the malware use a privilege escalation exploit (which are relatively numerous on linux) to access your data rather than some X11 flaw which depends on their code getting started by the user?
- array_key_first 11mo ago
  Because it's not an x11 "flaw" or exploit, it's just how X works. I also just don't buy the whole "well other stuff has exploits too" mentality. I mean, yeah, it does, maybe. So why bother creating a password to a service if their database is probably running Linux anyway and the rdbms is probably compromised and yadda yadda yadda. It's the kind of argument you can make for anything. Also no - privilege escalation is not "numerous" on Linux. It's very difficult to do in practice. It's only really a problem on systems built on old kernels which refuse to update. But those will always be insecure, just like running Windows 7 will be insecure.
  - atherton94027 11mo ago
    A quick search for "linux local privilege escalation" in the CVE database (https://www.cve.org/CVERecord/SearchResults?query=linux+local+privilege+escalation https://www.cve.org/CVERecord/SearchResults?query=linux+loca...) shows 25 results just for this year, so clearly these are very common. So basically we have two issues here: 1. either focus on security even though these changes don't really improve the threat model 2. or allow disabled users and anyone who uses accessibility features to use GUIs
ottah 11mo ago
A security in depth approach obviously. Run less, use vetted sources, when running suspect software execute in a properly sandbox context. Seriously what's the point of securing screenshot and key loggers if a malicious process has full access to the users home directory, auido stack, webcam and network? If you can't trust the process don't run it. If you have to run it, isolate all of it. Wayland gives you neither the freedom to safely tailor your security policy, nor the security guarantees to warrant its inflexibility.

surajrmal 11mo ago

The fact that desktop Linux is all or nothing in terms of privilege escalation is a design issue, however arguably Wayland gives us the tools to be more granular. Android has a permission system that makes sense can it's display manager is definitely closer in design to Wayland than it is to x11.

account42 11mo ago
Android is the antithesis of an open computing platform and if anything the Linux desktop should use it as an example of what not to do.
- surajrmal 11mo ago
  Android's sandboxing is doing work for the benefit of the user. This is similar to how your web browser sandboxes JavaScript. Not every app needs access to my location and providing it access shouldn't require root. The Linux ecosystem understands this and it's why there is a large push for sandboxing models in software such as flatpak. Even if you disagree with Android at some level it hard to argue that users benefit from being able to control what the software they run is capable of doing. Otherwise we wouldn't have filesystem permissions to begin with, in the name of "freedom".
  - amlib 11mo ago
    But them it's a question about how trustworthy an app is. Wouldn't it be better for software installed from your own distro repository to be fully trusted and require few or no security popups? After all, they are vetted to a much, much higher standard than any app store. Meanwhile flatpak apps and a random binary you've donwload get the full security isolation, because you can't trust third party devs.
    - surajrmal 11mo ago
      That's not a scalable solution as not every piece of software can pay the packaging cost for every Linux distro. Maybe it's fine for core system software, but it's too difficult to expect that model to work for all software. Imagine if every website you interacted with needed to ship new website updates by packaging it and getting it vetted. I think you still need a centralized distribution model even for things like flatpak to ensure some level of centralized auditing and revocation for software that has access to sensitive capabilities. However this doesn't necessarily need to be as large of a barrier for shipping updates as trying to package your software for a distro (and playing the game of trying to get your shared library versions aligned).