jcantero

Another relevant short story:

“I (28M) created a deepfake girlfriend and now my parents think we’re getting married” by Fonda Lee (2019)

https://www.technologyreview.com/s/614942/deepfake-girlfrien...

Yes.

> alias gmail='mutt -F ~/.mutt/muttrc_imap_gmail'

liferea - https://lzone.de/liferea/

It depends on who your publisher and target audience is. See this recent article: https://news.ycombinator.com/item?id=19708789

It's a blatant lie because the author of that code snippet is trying to trick the reader into thinking that Wayland's isolation somehow has been broken, but that's not true at all.

In the real world, any secure desktop solution is going to require a reliable execution environment ("security is only as good as your weakest link"). If you don't trust the user to properly handle that, then you must ensure they don't do anything stupid or dangerous to themselves by restricting what they can do. For desktop applications this usually means to execute them in a sandbox (such as Flatpak). QubeOS tries to do something similar, but stumbles upon the inherently insecure design of the X Server, and has to work around it running separate X server instances for each unreliable X client.

That link is a blatant lie. Redirect each wayland client's stderr to a different term and you will see that the process (keyboard/mice input + graphics output) isolation is still working as intended.

The headline is wrong. "Dreams Before the Start of Time" by Anne Charnock is the 2018 winner of the Arthur C. Clarke award: https://www.clarkeaward.com/2018-winner/

They must be referring to the Sir Arthur Clarke Award [1] (for space exploration), not the Arthur C. Clarke Award [2] (for Best Science fiction novel).

[1] https://en.wikipedia.org/wiki/Sir_Arthur_Clarke_Award

[2] https://en.wikipedia.org/wiki/Arthur_C._Clarke_Award

I fail to see how it can help in this case. The most fine-grained access you can achieve with SELinux are objects such as files or ports. What you need here is the ability to check if the other process has the permission to invoke certain operations from the current server through the Wayland protocol. It would be like arbitrary capabilities, but not linked to the operating system but to specific applications.

For example, in order for the Color Picker Tool to work, The Gimp should be marked with a "color picked allowed" capability, so when it asks the Wayland server for the color of pixels outside the surfaces it already owns, the server can check it and send the requested info. But a rogue program/process trying to scrap the screen content pixel by pixel shouldn't be able to do that. The inability to safely map processes to executables in Unix (and the possibility of manipulating their running code via exec(), library injection, ...) make it a very hard problem to solve without a paradigm shift that SELinux doesn't provide (as far as I can tell).

About how to use SELinux to ensure that a process with certain PID is running the intended executable and that it hasn't been tampered by the user (i.e. a rogue app running with user perms).

I haven't heard about that, can you please provide a link?

The reason that Wayland (or X11) protocol uses Unix sockets for communications is because there is not a hierarchical relationship between a client process and the server process (they can be even from different user "sessions"). Also, a client can be launched from anywhere, including a "shell" such as a /bin/bash interactive session.

How the wayland server and the shell are going to share (or agree to) that file descriptors or secrets in the first place? Or how can you ensure that the shell is not a rogue one?

> However the way Wayland (or its broader ecosystem) "fixes" security is just stupid. Instead of using a fine grained whitelisting based permission system to grant different clients all the permissions they need to do their work

Because you can't do that in Unix. You can't ensure that the process with PID 1234 is really executing /usr/bin/foo.