Date: Thu, 14 Nov 2013 00:36:09 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Ed Schouten <ed@80386.nl> Cc: freebsd-hackers@freebsd.org, rich@enterprisesystems.net, bug-followup@FreeBSD.org Subject: Re: misc/183495: utx.active not being updated correctly Message-ID: <20131113233608.GA8289@stack.nl> In-Reply-To: <CAJOYFBDEVjLzZ7Tq6bcTmo%2BBrSHJdoHjogX8Fy5gTBUUTt_uBA@mail.gmail.com> References: <CAJOYFBDEVjLzZ7Tq6bcTmo%2BBrSHJdoHjogX8Fy5gTBUUTt_uBA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 13, 2013 at 09:58:32PM +0100, Ed Schouten wrote: > [ +freebsd-hackers, to see whether this change would go in the right direction ] > It seems that the regression described in misc/183495 is unrelated to > utmpx alone. Unlike utmp, utmpx allows multiple entries per TTY. This > causes the issue to become actually visible. In some sense, having at most one entry per TTY is correct. Multiple entries arise mostly by bugs that do not delete an entry on logout or by (ab)use of /usr/bin/login's setuid bit. Also, it is not possible to isolate two users properly if they are using the same TTY. > telnetd uses login(1) to provide a login prompt, interactive shell, > etc. Looking at the source code of login(1), it seems that it never > attempts to call pam_cleanup() whenever the process terminates with > SIGHUP, nor does it protect itself against SIGTERM properly. The > following patch should fix this issue partially: > http://80386.nl/pub/login-signal-fix.txt > Still, one issue that remains is that the parent process can still be > killed using SIGKILL, thereby allowing you to circumvent > pam_cleanup(). What would be the right approach to fix this? Changing > the effective UID would solve this, but I don't feel really > comfortable to modify these kind of pieces of software. It's easy to > introduce security bugs. At least on stable/9, the login [pam] process has all UIDs equal to 0 and cannot be killed by a normal user. However, it can receive SIGHUP if the connection is closed. This should not lead to immediate termination, so the SIGHUP part of the patch seems correct, although I have not tested it. I am less sure about the SIGTERM part. Killing a login [pam] process may be a "doctor it hurts if I do this" thing. If SIGTERM is not left at its default action, perhaps it should kill process(es) associated with the session somehow (most simply, by cleaning up PAM and audit and exiting, which shuts down the session). The only way to avoid problems with SIGKILL would be to put the PAM and audit cleanup in a constantly running daemon such as init. I don't think this is worth it. Root should not kill -9 login [pam] processes. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131113233608.GA8289>