[orangeboats]

> But granting full rights to distro-provided programs like vim or xeyes is perfectly sane

Saying this after the whole XZ utils ordeal has happened is quite interesting.

Can you really guarantee that your distro is not compromised? And if it is compromised, how can you easily _discover_ that a program is doing something strange?

X11 (the one that most people are familiar with, not the locked down one with X security -- because the latter introduces compatibility issues) does not have an access control model where programs can request for specific permissions.

In other words, xeyes would just work(TM) without the user granting it permission to read global mouse pointer position. And simultaneously, the same is true for $compromised_distro_provided_program.

[TZubiri]

> the whole XZ ordeal

1 malicious package almost got distributed in 20 years of debian history?

>granting full rights to vim or xeyes

I'm not sure I get what's being discussed here. Standard Xorg runs without root already. And Xeyes definitely 100% run without root, I get why you would you run vim on root, to edit root files, but also don't? Especially if you have plugins, run simple programs like echo>> , ed, grep or nano.

[orangeboats]

Obviously, XZ happened on Debian. But $malware can occur on any Linux distribution at any time. For a recent example just look at Arch Linux.

Also, are we still assuming that we would still get only one attack over 20 years, instead of the frequency increasing to, say, one attack per year?

---

But those are not my original point, XZ utils was just an example.

My original point is that: why should we not practice defense-in-depth, where we make sure malwares have to jump through multiple hoops (and hope that they trip on one of them!) in order to launch an attack?

>I'm not sure I get what's being discussed here

I think it's the implication that any GUI program running under X can see any other GUI program and watch the user's interaction with the other programs. Vim is a CLI program though though...

[TZubiri]

>Obviously, XZ happened on Debian. But $malware can occur on any Linux distribution at any time. For a recent example just look at Arch Linux.

? Debian has a track record and a reputation. And Arch Linux has another, much worse, track record and reputation. You argue that it can happen to any distribution, yet it happens to one and not the other on a continuous basis, maybe it's not luck and maybe it has something to do with design and quality, quite possibly with the fact that packages are vetted and tested thoroughly before releases instead of being pushed as soon as they are available without much review.

>Also, are we still assuming that we would still get only one attack over 20 years, instead of the frequency increasing to, say, one attack per year?

If you want to make a wild bet, go to the casino. The probabilities given the current data is that there's roughly 1 malicious package over 20 years (I'm rounding up and counting the almost as a vulnerability).

>My original point is that: why should we not practice defense-in-depth, where we make sure malwares have to jump through multiple hoops (and hope that they trip on one of them!) in order to launch an attack?

I'm not convinced this is true at all. First of all you can run X servers under different users and as such isolate applications per user. As mentioned by other users, Xephyr makes nesting possible so as to not depend on root.

Thirdly, to the extent that it is possible to introduce a vulnerability through manipulating an X window, it will be possible to do so via other means like filesystem manipulation. That is, it's a system design tradeoff that if you run a malicious process as a user, the rest of your processes are almost guaranteed to be vulnerable.

Fourthly. Virtualization isn't a magic invokation that provides security on demand. You need to learn how the stuff works. For example, in the clusterfuck of container configuration, there's an Xauthority being shared that essentially undoes the whole containerization.

Virtualization is like a 5 inch thick wall, which sounds alluring to people that don't know what's on the other side of the perimeter, but it turns out that in order to do something useful, you need doors, and a house with 5 inch thick walls and a door without a key, is just as unsafe as a house with regular brick walls and a door without a key.

Virtualization is an antipattern, a patch to be applied under considerable stress, a glass to be broken in case of emergency, a move you pull when an engineering has been fired long ago and you don't want to learn about their system, a move you pull if you are in a big org where the role of the one who writes code and the one who runs commands on a system are separated by 5 more layers of roles, a hat on a skyscraper where we want to add the final few meters with pyramidal engineering, hoping that nobody asks us to add another floor.

Don't virtualize if you can avoid it.

[orangeboats]

>If you want to make a wild bet, go to the casino.

Are you seriously suggesting that the number of people attacking computer systems across the world, is the same as 20 years ago?

Wow.

No wonder why the X11 vs. Wayland argument can last for so long on HN when it's mostly ended in other Linux communities (sporatic controversies aside).

---

Furthermore. Nowhere did I mention the word virtualize in my original comment, and I do not think my comment warrants the paragraphs upon paragraphs of virtualization-bashing.

[TZubiri]

> Are you seriously suggesting that the number of people attacking computer systems across the world, is the same as 20 years ago?

Am I? Are you suggesting that systems 20 years ago were as secure as modern systems?

If the PoW cybersecurity theory is correct, the difficulty of atacking and defending is constant over time.

[orangeboats]

>If the PoW cybersecurity theory is correct, the difficulty of atacking and defending is constant over time

I am not the one arguing to weaken cyberdefenses and most certainly I did not write multiple paragraphs to bash on security measures ;)

[uecker]

It is the same issue with all sandboxing solutions. If your program does not work without giving it excessive permissions, it does not work. If we want to move to a version with minimal privileges, X would still seem like a good platform to work on this. But one would have to work on it, not decide that everything needs to be rewritten all the time.

[orangeboats]

> If we want to move to a version with minimal privileges

Then you would have to cut everything provided by the X protocol into many, smaller, controllable pieces. Because if the permission control is just a switch that says "ability to communicate with the X server", then the whole exercise is rather moot, isn't it.

And when you cut the protocol into smaller pieces...

[uecker]

No, there is already a secure mode which in the past worked fine but was bit too restrictive for modern clients, and there already exist hooks for fine grained access control.

[hulitu]

> Saying this after the whole XZ utils ordeal has happened is quite interesting.

You do realize that XZ was on github. (Microsoft, PRISM etc.)