4 ms·
PAM changed everything, back in the 1990s. * https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.html https://jdebp.uk/FGA/dont-abuse-su-for-dropping-pr
by JdeBP 3y ago
PAM changed everything, back in the 1990s.
* https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.html https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.h...
- aidenn0 3y agoTL;DR: PAM requires session cleanup, which might require extra privileges.
- tedunangst 3y ago> aside from a few hold-out BSDs and BSD-derived systems One wonders if perhaps these systems weren't on to something.
- donio 3y agoIt's quite possible to build and use sudo without PAM support even on Linux, most distributions just tend to build everything in "kitchen sink" mode. If I remember right on Alpine it's PAM-free by default so it doesn't need to fork. On Gentoo it's behind a USE flag.
- JdeBP 3y agoBack in 2017, the Linux developers' notion was that not even all of this PAM stuff was enough for the parent process to be doing. Their then asserted correct solution to TIOCSTI was that su, sudo, doas, and the like should open a pseudo-terminal and get involved in pumping pseudo-terminal I/O. They were to do this as well as, presumably, managing all of setsid(), child process stopping/suspending with a signal, and setlogname() for the new session; to keep what the old books all say about keeping the same logname even though one has switched user, and being able to use the suspend command in the second shell. * https://www.openwall.com/lists/oss-security/2017/06/03/9 https://www.openwall.com/lists/oss-security/2017/06/03/9 * https://www.openwall.com/lists/kernel-hardening/2017/05/10/34 https://www.openwall.com/lists/kernel-hardening/2017/05/10/3... Six months ago, TIOCSTI became optional in Linux.
- tedunangst 3y ago> Another point Alan brought up is that if a program is careless enough not to allocate a new pty, it's probably also careless enough not to close any fd's that might be open in the parent shell or by the program itself. Oof, weird inference. File inheritance is pretty well known. TIOCSTI is really esoteric.
- garaetjjte 3y agoRequiring pam_close_session is just bad design - if it needs special cleanup, pam_open_session should grab process pidfd and spawn separate monitor process (or pass pidfd to existing daemon).
- Spivak 3y agosudo is that monitor process, it's the same with how containerd and podman work, it's much much easier to babysit a process when you're its parent.
- formerly_proven 3y agoPAM predates pidfd by about 25 years or so, though it's really weird how steadfastly unix heritage systems avoided handles for important things, resulting in race conditions and security issues all over the place.
- fragmede 3y agoWhich is definitely what you want in your authentication subsystem.
- jdiff 3y agoThat seems like a disingenuous title, it's not abusing su, that's just one of the many things that tool was used for. That was never a bad practice, the tool just changed and pulled the rug out from under very many programs.
- rando14775 3y agoThis article's list of privilige dropping tools is missing setpriv(1) from util-linux, which is the only one actually installed on my system.
- JdeBP 3y agosetpriv is very much a Johnny-come-lately here, dating from 2013, which was almost a decade and a half afterwards. If you have BusyBox installed, you have runit's chpst and setuidgid built in to it. And most Linux distributions not only package that but also package one or more of these toolsets; most often daemontools and runit, but nosh has an Arch package for example.