How about ptrace(), depending on how your system is configured, an attacker running under your own user account could do similar damage to any process you run, make your browser display fake login forms, steal saved application passwords, etc.
Once someone has access to your the user account of someone with sudo it's game over, there's just too many ways to elevate, I couldn't even name them all. They could even just straight up "tmux attach -d" and steal your logged in root shell.
> there's just too many ways to elevate
That's a problem that a lot of different people are trying to tackle because there's a lot of holes to plug.
* Wayland is plugging the Xorg hole where an app can listen or send keystrokes to other applications.
* sudo plugs this hole (by default) by requiring your password and binding your ticket to a single tty.
* Polkit plugs this hole (with Wayland's help) by having privileged dialogs and authenticating individual applications (i.e. dbus clients) instead of the user as a whole.
* The kernel switch plugs the ptrace hole.
* Flatpak and other namespacing frontends are working on the filesystem/network holes by keeping apps in their own little world unless allowed out.
* SELinux also lives in this space but it's a step removed preventing compromised apps the ability to use various escalation tricks in the first place.
We're closer than we've ever been. Now is pretty much the worst time to throw up our hands and say it can't be done.
- 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.
You can only ptrace an application when you are its parent. 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.
> Messing with environments variables and shell files.
Not when you don't have access to their home directory and all your file accesses are via XDG portals.
> You can change a user's entire shell
There are a number of access controls preventing this. First, modifying a users passwd entry is a privileged operation and using `chsh` requires the user's password.
> replace a user's compositor with a customized one
The compositor is the security boundary. Of course if you replace it the model is broken but if you have a POC where a program running as the user can change a users entire compositor to a malicious one I would love to see it.
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.
SELinux isn't designed to stop you from calling sudo. But it does make sure that the scope of a what compromised application running as your user is limited. It's not directly related but MAC is a piece of the puzzle.
> if not all of the important data will be in the user's home directory
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.
> 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.