[erlkonig]

At more centrally-administered sites, a user might not even have the ability to change an X server option. The idea of making a toggle via xset sort-of makes sense, but seriously, isn't the idea generally that you trust the apps you're running anyway. And doesn't a vastly different wrong number in some X call at least produce an effect that makes you aware of the problem (I know, that doesn't make a X server more stable...). It's just baffling to make something near-universally available less so. The next new CPU thing could be bigendian - or quantum, but who knows what byte order that would prefer.

[eikenberry]

> but seriously, isn't the idea generally that you trust the apps you're running anyway

Yes, and it is a bad idea. Trusting your apps is how we've gotten in the state we are today with virus scanners and the like. Generally you want to trust as little as possible (at least in tech).

[sprash]

> the state we are today with virus scanners and the like. Generally you want to trust as little as possible

This is only true if you run closed source software on non-free systems. I honestly can't remember that I ever had to use a virus scanner on Linux or UNIX.

[charcircuit]

You still have to worry about vulnerabilities. It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys, but unfortunately this is how many Linux distros, ignoring Android based ones, work.

[sprash]

> It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys

So far this never happened on free operating systems running free software on X11. Hence I refuse to believe this is a realistic threat scenario. Severe sandboxing is only necessary for untrusted/non-FOSS software otherwise it just harms user experience an productivity especially for power users.

[comex]

Do you use a modern browser? If so, you use a piece of software that has been exploited many times by attacks in the wild. Those attacks were mostly targeting either a phone OS or Windows or macOS - not because there is anything in desktop Linux that would defend against those attacks, but because it is less popular. Perhaps some attacks did target desktop Linux; it’s hard to tell because few in-the-wild attacks are publicly documented in detail (although Project Zero has a spreadsheet of bugs known to have been exploited in the wild [1]). Regardless, at best you are relying on security by obscurity. And that’s despite the fact that modern browsers already have built-in sandboxing; without it the situation is worse.

[1] https://googleprojectzero.blogspot.com/p/0day.html?m=1

[hulitu]

The modern web browser is a RCE vulnerability in itself. That developers seems to think this is a good idea is beyond my comprehension.

On a modern system the browser should run ideally in a virtual machine without any access to hardware or filesystem.

[chlorion]

There are code execution vulnerabilities in common software, including the kernel and your favorite browser, probably at least once a month, and likely more.

You can go checkout a CVE listing website if you don't believe it.

The thing you may be not thinking of, is that the software itself doesn't have to be intentionally designed to be malicious for it to do harm. Lots of software is written in memory unsafe languages and is full of nasty subtle bugs that can be exploited.

There are also supply chain issues, your favorite open source project's maintainer might have their github credentials phished, and code to do something nasty sneaked into an otherwise normal seeming update. This has happened and is not just a theoretical scenario!

[charcircuit]

Quassel is an IRC client licensed under the GPLv2 and GPLv3. CVE-2018-1000178 is a RCE vulnerability for it.

Yes. It is possible.