Firejail

I do use Linux (almost) exclusively, but I'm well aware of the security limitations.

Forget this keylogger. All you need is to somehow write a single line into .profile or .bashrc, which basically every executed program can do, and you own the user account. You can intercept every program with wrappers by changing PATH or adding desktop entries in .local/share/applications, extract all data from applications, use LD_PRELOAD like shown in the submission ... the possibilities are endless.

There isn't even a single decent dynamic firewall with those annoying popups.

Apart from SELinux, there is also firejail [1], which I use to sandbox browsers. Flatpak and Snap are also trying to solve both the packaging and the sandboxing aspect, with moderate success. They also increase the risk due to lack of centralized package ownership, so require a very solid sandbox.

The only reason why the Linux desktop is somewhat secure is the reliance on official package repos, the trustworthiness of the open source communities, and the and the relatively small target group.

I do believe that the path forward has to be Mac OS/Android/iOS style sandboxing - especially for everything not directly from an official repo, but there seems to be relatively little interest in the ecosystem.

Non Linux specific sidenote: ever notice how many VS Code extensions download random binaries from the net? Or just that they can execute arbitrary code? Compromising one of those could lead to some glorious…

True there's no sandboxing by default on a typical linux desktop but I think the key difference between the linux distributions and Android security models is that your linux distribution is supposed to run trusted free software whereas your Android device is probably going to run some proprieatary untrusted apps.

That's why sandboxing is very necessary on Android and not so much on your linux box.

Now I agree you should sanbox everytime you can especially when linux is well capable of it, that's why I use firejail on my desktops so I get all the awesomeness of my favorite distributions AND strong sandboxing with real ease of use.
https://firejail.wordpress.com/

One cool trick is to hook "sudo firecfg" in your package manager post operations so whenever you install new software it get sanboxed if a firejail profile is available (which is generally true). There may be a smarter way to do just that though?

That xkcd post makes a very good point indeed (that's why everybody should lock whenever afk, encrypt and use strong passwords of course)
But I also think you should also worry about those backdoor issues:
https://www.replicant.us/freedom-privacy-security-issues.php
https://libreboot.org/faq.html#intel

I am just its (mostly happy) user. I wrote that rule on my phone so you are right, it is not complete. On the other hand raw sockets require CAP_NET_RAW capability which is often assigned to root only so running a capability-untreated binary as an unprivileged user should not allow any raw socket ops (ping often uses file capabilities or setuid root).

AFAIK it requires root to load/reload profiles. And that is fine for me, my use-case is hardening of services running on my server.

For ad-hoc restriction of untrusted software you can already use stuff like FireJail https://firejail.wordpress.com/

But I agree that software developers know their software the best so they should be the ones writing the rules and ideally configure them depending on automake/configure paths (i.e. different PREFIX, this software/profile separation is annoying) but pledge() looks too old and non-flexible for such a job IMO. Most software need file ops but don't need to write everywhere.

You can use Flatpaks to basically solve this issue. Most applications nowadays are already available as Flatpaks, the ones that aren't probably have been reviewed by your distribution. Stick to official repositories and there shouldn't be any worries really. Of course for the average user this kind of discipline might be impossible, but for power-users out there: https://firejail.wordpress.com/

You could also play a bit with writing SELinux or AppArmor policies, although I grant that most people don't give a fuck and just want to get their computing done.

Opting for a Wayland-compliant display server instead of XOrg will also provide you with similar benefits such as preventing applications from capturing your key-presses without you knowing or recording your screen without your permission.

Via CLI you can, but GUI apps connect to your X server session, and then the fun begins - any application you allow to connect can essentially capture your keyboard, mouse, clipboard and a ton of other fun things,as there is no sandboxing applied between them. It's inherent in the design of the X protocol.

There are solutions that are intended to force the sandboxing by opening a new Xserver for every application, e.g. Firejail [0], but that comes with another set of interoperability problems.

Wayland was supposed to address some of these concerns, but it will only do so for applications that natively talk wayland protocol, not the ones that connect through x-protocol via xwayland

[0] https://firejail.wordpress.com/

Because it's a legitimate behaviour. htop needs to do this, it's literally its main feature.

You can use hidepid=2 to prevent users from seeing other user's processes list.[1]

But I don't want my OS to ask me "do you want to allow htop to access the list of your processes" — à la Windows Vista — every time I want to run htop to see my user processes.

The issue here is closed source software with no way to inspect what they do.

If one really want to run closed source programs which were not vetted by their distro's maintainers, they should use firejail.[2]

[1] https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/

[2] https://firejail.wordpress.com/