tmux Privilege Escalation

- Even if you use the kernel switch you can still ptrace an application on startup, do you read the code for every .desktop composing your launchers?

- You can trivial add say, a modified web browser or terminal emulator to a user's PATH.

- You can add aliases to a user's shell configuration

- You can change a user's entire shell to a shim designed to fool them into thinking things are normal

- You can replace that desktop update notifier with a tweaked one that logs that root password first

- Wayland too will fall when you replace a user's compositor with a customized one, must of Wayland's security improvements have actually just been moving things from display server to compositor. Simply re-configuring the user's session choice will likely be enough to do this. Just like changing your shell.

- The PolKit "hole plugging" you suggest only works if there's no way to recreate a dialog which would look exactly the same, so I'm not sure how it has any relevance here

- SELinux more prevents problems between user accounts, as the isolation is designed to work, not within them and not for authorized escalation tools like sudo

- In the case of desktop systems it's also important to remember that most if not all of the important data will be in the user's home directory. https://xkcd.com/1200/

This will not be possible, as long as the same user controls their own configurations for core stuff like shell and launchers. User accounts weren't designed for this level of isolation. Make a separate user if that's what you want. This is why most distros run all servers under different user accounts out of the box. If you're concerned about the security of say, your browser, you should probably consider adding user account isolation to it too, on Android every single app gets it's own account.

If your threat model involves giving untrusted users access to a sudoer, you're not going to have a good time. User accounts are still the primary form of isolation on Linux, it's not a sandboxed mobile OS, maybe Flatpak will change that someday, but for now we have barely even started on this sort of switch to an entirely different security model.

For completeness, the same can be done with screen:

screen -S session_name -p window_number -X stuff "whoami^M"

> Modifying system-wide desktop files is a privileged operation and flatpak's filesystem namespacing prevents applications from messing with the launchers in your home directory.

Okay, but let's jump over to reality for a second, no one uses Flatpak and your desktop shortcuts are on your desktop, not the system one, so are your other commonly invoked applications, due to the unnecessary complexity Flatpak introduces I feel it's unlikely to see widespread adoption in the near future.

> GDM launches your session and is outside your control as an unprivileged user and if the compositor dies so does your session. You can't 'swap' it and your malicious compositor can never be shown as a choice in GDM since those preferences require root to modify.

Did they change it so GDM no longer prefers your ~/.xinitrc if available?

You may also be able to LD_PRELOAD the compositor from your ~/.xprofile, but I haven't done any experiments there.

> Yep, which is why apps won't have access to it except for the files the users chooses to give the application via a system dialog.

This entire concept is nothing more than an annoying joke not widely deployed on any desktop system today.

Consider also that such an extreme level of sandboxing could also prevent malicious access to your tmux session and prevent this issue entirely in such a case, so why would this even be considered a problem if you're talking about that level of sandboxing?

Perhaps I was a too dismissive of it - but in any case it's a complete change of security model and its not clear that tmux is what would be at fault under such a model or if something else would be expected to protect it's session from access. Maybe some magic Flatpak garbage should be blocking access or something. Just slap more layers on it, I'm sure that'll fix it and not annoy the hell out of anyone.

Edit: because there is occasionally confusion on this point I recently documented it here: https://github.com/tmux/tmux/wiki/Contributing