X.Org security advisory: root hole via rogue hostname

It's worth nothing that OpenBSD uses BSDAuth, not PAM. Unlike PAM, a program doesn't need root permissions to authenticate against the local passwords. PAM uses shared libraries and thus operates with the credentials of the calling process, whereas BSDAuth uses tiny executable commands in /usr/libexec/auth (with set-user-id root, but requiring auth group to execute). OpenBSD is really rigorous about creating a unique user and group for every little service and role. This helps to mitigate privilege escalation attacks.

But that only solves one of the two issues. You still need root to setuid(). But OpenSSH, for example, uses a multiple process model to isolate the privileged process; and it's the unprivileged process that does network I/O. Theoretically XDM could be setup similarly, so that only an unprivileged fork runs all the startup rc code and interacts with the environment, asking the privileged process to create a new user session when necessary. AFAIK the OpenBSD folks haven't hacked XDM to do this, but they use this multi-process model for all of their new services that require preservation of root credentials (excepting simple authentication, which is solved by BSDAuth).

Yes, but the files which are readable and writeable by you are a subset of those readable and writeable by root. If only files readable and writeable by you can get deleted/modified, that's less damage, and easier to clean up, than if all files can get deleted/modified.

Further, any exploit could do

"rm -rf /"

The one owned by you instead of root will end up doing the exact equivalent of

"rm -rf $HOME/*"

plus probably a bit more damage, even though it can't delete your whole system. The advantage is that it's limited to *only* your files, and not the whole system.

Also, the files which you care about, and are readable and writeable by you, are not the files which anyone else who uses that computer cares about, e.g. partner, kids, guests. So if you manage to get exploited and all your files are deleted, that's still a win for e.g. your partner. More importantly to you, if your partner gets exploited, all *your* files are still safe.

Finally, it's easier to restore just your home dir from backup than it is to reformat, reinstall your whole OS, including packaged applications (do you have a backup not only of /home, but also a list of which packages were installed, and all your changes to /etc?) and then anything you might have manually put in /usr/local, and *then* restore your home dir from backup.

This is why kernel mode settings + running X as an unprivileged user *will* be a blessing.

Preventing "rm -rf $HOME" is what Mandatory Access control such as SELinux, Tomoyo, or AppArmor were designed to prevent.

I was first thinking that untrusted DHCP servers are used in many places, such as public wireless networks. But apparently this only affects hosts that set their hostname based on DHCP information. I haven't seen any typical Linux laptops do that, the hostname is usually set in a configuration file. Are there widely-used distributions or setups where this could be a problem, that is, machines that often use random DHCP servers and do set their hostname based on DHCP?