3 ms·

> an application that has access to your display can do stuff with other applications. Well, of course, that's the whole point of using "applications", isn't i

> an application that has access to your display can do stuff with other applications. Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data! Regardless of x11/wayland, the application "vim" can read (and change!) all files in my home dir. Do you also consider that a security issue? If you want to run some weird application that you don't trust, you should run it inside a container. But that has nothing to do with display systems.

samus 2y ago
It kind of is, and it doesn't really have to do with an application not being trustworthy. It's a defense in depth approach against app that become compromised through exploiting bugs with security implications. The attack surface of Vim is admittedly small, but the browser is a much bigger target. I want my browser to download files, upload files that I provide, and various other things on an allow list, but not more. IDEs, the tools invoked by them, and their build artifacts should have access to the project assets and not much more. There are certainly applications that require more privileges, but I'm sure we can come up with ways to restrict them as well. The problem is that it's quite late to retrofit it onto desktop Linux. Containers are not designed to be security boundaries. They isolate their contents from the host system, but not primarily because of security. They can be used for security, but certainly not with default settings.
- enriquto 2y ago
  > Containers are not designed to be security boundaries. So you'd prefer your graphics system to act as a security boundary? Seems very weird to me. Containers are clearly the right tool for this job, for they can run as well for non-graphical programs.
  - nolist_policy 2y ago
    The graphics system absolutely is a part of the security boundary. You can pass through your X11 or Wayland server socket in the container to run graphical applications. This is more of less what a Flatpack is.
  - PlutoIsAPlanet 2y ago
    Yes, the windowing system requires such to prevent applications with less privileges spying or controlling those with more. On X, it is possible for an exploit in a browser to gain root if you have an application opened as root. Although such exploit would be extremely difficult to pull off, state actors will do anything for specific targets.
    - kwhitefoot 2y ago
      > state actors will do anything for specific targets. That's either not a problem for me because I am of no interest to them. Or it is a problem that no amount of fiddling with software can mitigate because they can just beat me until I give up. See https://xkcd.com/538/ https://xkcd.com/538/
  - samus 2y ago
    It has to be. The capabilities exposed via the X socket are way too powerful since they allow the application to mess with any other application running on that X server. There are sandboxing solutions which give each applications its own X instance, which is quite similar to the way Wayland isolates applications from each other, and shares the same disadvantages.
    - iforgotpassword 2y ago
      Usually people run all their apps unsandboxed anyways, so cool that Wayland prevents me from accessing any other app via its protocol - too bad I can just open any other process's memory via /proc, or read any sensitive data it stored in $HOME. It's been a long time since I daily drove Windows, but I'd assume it's still the same situation over there. I don't care. Sandboxing is annoying, cumbersome. I'm not going to create a container for every single app I run, so Wayland brings zero additional security. If once in a honeymoon I need to run shady software I use a VM.
      - samus 2y ago
        Of course it has to be used with another sandboxing layer to be effective. You don't have to create a container by yourself, a good desktop will do it for you. One such solution is Flatpak. Many applications don't work that great with Flatpak yet and require quite sweeping additional privileges, but we will probably see improvements over time. There's nothing wrong with users deciding to just have a common folder with all their data, but some applications are of more sensitive nature than others and it should be possible to secure them better. For example password managers or terminals.
- webreac 2y ago
  What do you mean by "The attack surface of Vim is admittedly small" ? Recently I had to access a file owned by root. The IT gave me the permission to do sudo /bin/less /etc/the_file. That was enough to launch a shell with root permissions. If someone can send commands to Vim, he can launch any command and own your computer.
  - Bu9818 2y ago
    They're talking about the attack surface to get accidental code execution from opening files that try to exploit vim. Integrating shell commands with vim/less is a valid feature.
  - samus 2y ago
    That was indeed a bit silly by IT. They could have written a script that gives you a copy of the file and then deletes it after you're done with it, sort of like what sudoedit does. Or just let you sudoedit that file since they obviously had no problem effectively granting you write access.
amelius 2y ago
> Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data! Why do you think webbrowsers go through great lengths to isolate different tabs from each other?

samus 2y ago

It kind of is, and it doesn't really have to do with an application not being trustworthy. It's a defense in depth approach against app that become compromised through exploiting bugs with security implications. The attack surface of Vim is admittedly small, but the browser is a much bigger target. I want my browser to download files, upload files that I provide, and various other things on an allow list, but not more. IDEs, the tools invoked by them, and their build artifacts should have access to the project assets and not much more. There are certainly applications that require more privileges, but I'm sure we can come up with ways to restrict them as well. The problem is that it's quite late to retrofit it onto desktop Linux. Containers are not designed to be security boundaries. They isolate their contents from the host system, but not primarily because of security. They can be used for security, but certainly not with default settings.

enriquto 2y ago
> Containers are not designed to be security boundaries. So you'd prefer your graphics system to act as a security boundary? Seems very weird to me. Containers are clearly the right tool for this job, for they can run as well for non-graphical programs.
- nolist_policy 2y ago
  The graphics system absolutely is a part of the security boundary. You can pass through your X11 or Wayland server socket in the container to run graphical applications. This is more of less what a Flatpack is.
- PlutoIsAPlanet 2y ago
  Yes, the windowing system requires such to prevent applications with less privileges spying or controlling those with more. On X, it is possible for an exploit in a browser to gain root if you have an application opened as root. Although such exploit would be extremely difficult to pull off, state actors will do anything for specific targets.
  - kwhitefoot 2y ago
    > state actors will do anything for specific targets. That's either not a problem for me because I am of no interest to them. Or it is a problem that no amount of fiddling with software can mitigate because they can just beat me until I give up. See https://xkcd.com/538/ https://xkcd.com/538/
- samus 2y ago
  It has to be. The capabilities exposed via the X socket are way too powerful since they allow the application to mess with any other application running on that X server. There are sandboxing solutions which give each applications its own X instance, which is quite similar to the way Wayland isolates applications from each other, and shares the same disadvantages.
  - iforgotpassword 2y ago
    Usually people run all their apps unsandboxed anyways, so cool that Wayland prevents me from accessing any other app via its protocol - too bad I can just open any other process's memory via /proc, or read any sensitive data it stored in $HOME. It's been a long time since I daily drove Windows, but I'd assume it's still the same situation over there. I don't care. Sandboxing is annoying, cumbersome. I'm not going to create a container for every single app I run, so Wayland brings zero additional security. If once in a honeymoon I need to run shady software I use a VM.
    - samus 2y ago
      Of course it has to be used with another sandboxing layer to be effective. You don't have to create a container by yourself, a good desktop will do it for you. One such solution is Flatpak. Many applications don't work that great with Flatpak yet and require quite sweeping additional privileges, but we will probably see improvements over time. There's nothing wrong with users deciding to just have a common folder with all their data, but some applications are of more sensitive nature than others and it should be possible to secure them better. For example password managers or terminals.
webreac 2y ago
What do you mean by "The attack surface of Vim is admittedly small" ? Recently I had to access a file owned by root. The IT gave me the permission to do sudo /bin/less /etc/the_file. That was enough to launch a shell with root permissions. If someone can send commands to Vim, he can launch any command and own your computer.
- Bu9818 2y ago
  They're talking about the attack surface to get accidental code execution from opening files that try to exploit vim. Integrating shell commands with vim/less is a valid feature.
- samus 2y ago
  That was indeed a bit silly by IT. They could have written a script that gives you a copy of the file and then deletes it after you're done with it, sort of like what sudoedit does. Or just let you sudoedit that file since they obviously had no problem effectively granting you write access.

amelius 2y ago

> Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data! Why do you think webbrowsers go through great lengths to isolate different tabs from each other?