From owner-freebsd-security@FreeBSD.ORG Tue Sep 3 07:51:35 2013 Return-Path: Delivered-To: freebsd-security@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 ESMTP id D871ED1C for ; Tue, 3 Sep 2013 07:51:35 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 986FB2F11 for ; Tue, 3 Sep 2013 07:51:35 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id B6E124164; Tue, 3 Sep 2013 07:51:34 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id B452433992; Tue, 3 Sep 2013 09:51:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Slawa Olhovchenkov Subject: Re: OpenSSH, PAM and kerberos References: <20130829004844.GA70584@zxy.spb.ru> <86d2ovy64p.fsf@nine.des.no> <20130830100926.GU3796@zxy.spb.ru> <20130830103009.GV3796@zxy.spb.ru> <86sixrwdcv.fsf@nine.des.no> <20130830131455.GW3796@zxy.spb.ru> <8661uj9lc6.fsf@nine.des.no> <20130902181754.GD3796@zxy.spb.ru> Date: Tue, 03 Sep 2013 09:51:35 +0200 In-Reply-To: <20130902181754.GD3796@zxy.spb.ru> (Slawa Olhovchenkov's message of "Mon, 2 Sep 2013 22:17:54 +0400") Message-ID: <867geywdfc.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 07:51:35 -0000 Slawa Olhovchenkov writes: > If in this scenario on step 4 insted fork do pthread_create we don't > lost stored credentials and (I think) have full-synchronized thread > (new thred only work by request from parent and only for short time). It's not quite that simple. When a service module calls a conversation function, the event loop resumes until it receives an answer from the client. This is why PAM needs to run in a separate thread or process. OpenSSH was not designed to be multi-threaded, and we can't be sure there won't be conflicts. Another problem is that libpam loads shared objects (the modules) when it runs, which may result in conflicts as well - espcially with pam_ssh(8). The proper solution would be an identification and authentication daemon with a well-designed RPC interface and mechanisms for transferring environment variables, descriptors and credentials from the daemon to the application (in this case, sshd). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no