From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 13 23:40:01 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C50EC438 for ; Wed, 13 Nov 2013 23:40:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A8F22AB5 for ; Wed, 13 Nov 2013 23:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rADNe1Vo008887 for ; Wed, 13 Nov 2013 23:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rADNe1WU008886; Wed, 13 Nov 2013 23:40:01 GMT (envelope-from gnats) Date: Wed, 13 Nov 2013 23:40:01 GMT Message-Id: <201311132340.rADNe1WU008886@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jilles Tjoelker Subject: Re: misc/183495: utx.active not being updated correctly X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Jilles Tjoelker List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 23:40:01 -0000 The following reply was made to PR misc/183495; it has been noted by GNATS. From: Jilles Tjoelker To: Ed Schouten Cc: bug-followup@FreeBSD.org, rich@enterprisesystems.net, freebsd-hackers@freebsd.org Subject: Re: misc/183495: utx.active not being updated correctly Date: Thu, 14 Nov 2013 00:36:09 +0100 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