Hacker News new | past | comments | ask | show | jobs | submit login

>> Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack...

The security model in Wayland seems to keep the application largely isolated from its environment. No warping the mouse pointer, no reading pixels, no understanding of what the user might be doing outside the application window. I can agree with all of that in principle. It is not the applications place to move anything on the desktop including itself. Those are to be done by the user. Also for consistency this kind of thing has to be done by the DE.

It was also nonsensical to have have applications be responsible for remembering their own positions instead of the "window manager". Read that again "window manager" ;-)




> The security model in Wayland seems to keep the application largely isolated from its environment.

I really don't see what good that is when considered in the greater context of the Linux desktop paradigm, wherein any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit. To get any real security benefit from Wayland over X, you'd have to abandon the entire Linux desktop paradigm and use a completely new ecosystem as different from the traditional linux desktop as Android is.

If you just use Wayland as a drop-in replacement for X (as GNOME/Wayland and KDE/Wayland are essentially doing), you're still screwed six ways to Sunday.


> I really don't see what good that is when considered in the greater context of the Linux desktop paradigm, wherein any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit. To get any real security benefit from Wayland over X, you'd have to abandon the entire Linux desktop paradigm and use a completely new ecosystem as different from the traditional linux desktop as Android is.

It doesn’t require changes as deep as you’re implying (although I would say moving away from the traditional UNIX permissions model would ultimately be a good thing). It can be beneficial with existing application confinement mechanisms like Flatpak. You can restrict a Flatpak app from accessing your $HOME, but if it’s given access to your X server it has a lot more access than it likely needs. My understanding is the situation is better with Wayland, provided you only give it access to the Wayland socket and not the X11 socket.


Why do Linux heads this needless containerization thing to themselves? There are zero new desktop apps coming; those in use are F/OSS and have been thoroughly reviewed for like 20 years. What's the threat? At best, it disturbs user file-based workflows and puts additional work onto developers who are few and far between anyway. Distros have worked well for a long time - much better than Win or Mac sw updates. If you want to compile your own app, it's well supported. We don't have a rush of new unstable must-have libs to compile against all of a sudden.


The problem is not trusting the application, but that application having to manage untrusted data. Let’s say you have a trusted open source pdf reader. It can easily be infected by a pdf that exploits a memory bug in it.


Just wait until systemd grows a ui toolkit :D


Will that come before or after the SystemD kernel? I assume the systemD web browser comes after the UI toolkit?


>> If you just use Wayland as a drop-in replacement for X (as GNOME/Wayland and KDE/Wayland are essentially doing), you're still screwed six ways to Sunday.

No, you're only screwed 4 or 5 ways. Applications can't screen capture, and they can't monitor the keyboard input to other applications.

Your points on other security issues are valid, but just because there are 6 different ways a program can dig into your system is no reason not to plug some of those holes. Wayland does that.

IMHO we need to restrict a bunch of system calls so they can only be used by the GUI toolkit. Then only files selected by the user could be accessed by an application. Of course CLI programs and other cases need permission too, so there is some complexity to work out. But this would allow a random application to use the system installed GUI toolkit and access only what the user specifically says through interactions.

Better security doesn't have to be hard, but it does require that changes be made.


> any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit.

Not that I'm a fan of it or that knowledgeable about the subject, but isn't this sort of where Flatpak comes in where applications have to be given permission to access some of these?

I know that Fedora is very clearly moving toward the Silverblue (OSTree) endgame where the underlying system is immutable and Flatpak is the default for user applications on top.


Just because the existing situation on Linux is terrible from a security point of view, it doesn’t mean we shouldn’t start fixing it.

Not being able to install a keylog from an npm package is already a huge improvement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: