@ska

Preventing any client process upserting a USER_PROCESS record type for anything other than its own PID is probably a quite strong security check. More restrictive than group membership checks.

I checked util-linux's agetty and login, as a start. They only put their own PID in the process ID field. And they already look for an existing record to update by PID.

So it's an idea worth considering.

https://github.com/util-linux/util-linux/blob/master/login-utils/login.c#L1422

#ttylogin #utmps

@ska

DEAD_PROCESS is harder, as it's often written by the parent process on Linux. (On FreeBSD, the PAM session holder process declares itself dead, because pututxline() is called both ways within the pam_lastlog module.)

But it might be worth adding a check that a process really does not exist before a client (that isn't that very process declaring itself dead) can declare it to be dead.

#ttylogin #utmps

@JdeBP You're not wrong, but tbh, utmp is, has always been and will always be a hack; utmps exists because musl doesn't implement utmp (because you can't make it half-secure without a daemon, and @dalias thinks it's user spying anyway) but Adélie Linux people wanted to make 'who' work. 😅

Doing user accounting seriously would require a complete redesign of the whole thing, not only to have serious APIs instead of the barely usable utmp/x ones, but first and foremost to decide what exactly we want to log and for what purpose, and even what constitutes a user.

utmp is not the place to do it. I intend to study that domain at some point, as part of something that is long overdue: I want to take a long hard look at PAM and design something similar in a secure way, that doesn't encourage applications to share their address space with 3rd party authentication modules. And when we talk authentication, we can also talk legitimate user accounting.

The plan is to apply for an @nlnet grant to do that work, but first I need to deliver on my current one, s6-rc for Alpine 😁