Multiple security issues in GNU Screen

Note: In Debian, GNU screen is not installed with setuid-root privileges.

Likewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.

If one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins.

https://jdebp.uk/FGA/unix-login-database.html

The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.

The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.

Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.

* https://skarnet.org/software/utmps/

Both the BSDs and M. Bercot have improved the situation with pututxline(), but it's still not out of the woods yet.

I set TMPDIR to $HOME/tmp because of that.