Hacker News Reader

Comment by samus | Hacker News Reader

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.

View on HN

> 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.

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.

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.

> 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/

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com