From owner-freebsd-security@FreeBSD.ORG Tue Sep 3 20:20:53 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2BABE72F for ; Tue, 3 Sep 2013 20:20:53 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id A54B22650 for ; Tue, 3 Sep 2013 20:20:52 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:61fd:95c3:8111:539a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 3EECA4AC2D; Wed, 4 Sep 2013 00:20:43 +0400 (MSK) Date: Wed, 4 Sep 2013 00:20:38 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1289783626.20130904002038@serebryakov.spb.ru> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Subject: Re: OpenSSH, PAM and kerberos In-Reply-To: <86fvtludku.fsf@nine.des.no> References: <86sixrwdcv.fsf@nine.des.no> <20130830131455.GW3796@zxy.spb.ru> <8661uj9lc6.fsf@nine.des.no> <20130902181754.GD3796@zxy.spb.ru> <867geywdfc.fsf@nine.des.no> <20130903083301.GF3796@zxy.spb.ru> <86y57euu8y.fsf@nine.des.no> <20130903093756.GG3796@zxy.spb.ru> <86ppsqutw7.fsf@nine.des.no> <998724759.20130903142637@serebryakov.spb.ru> <20130903103922.GI3796@zxy.spb.ru> <6110257289.20130903145034@serebryakov.spb.ru> <86d2oquopo.fsf@nine.des.no> <226539732.20130903154908@serebryakov.spb.ru> <8661uiujin.fsf@nine.des.no> <1734535072.20130903174359@serebryakov.spb.ru> <86vc2it2ip.fsf@nine.des.no> <1601348478.20130903182152@serebryakov.spb.ru> <86fvtludku.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@FreeBSD.org, Slawa Olhovchenkov X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org 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 20:20:53 -0000 Hello, Dag-Erling. You wrote 3 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., = 19:31:13: >> How does it affect second-most-used-login application -- login(1)? DES> I don't think login(1) is anywhere near second place - but yes, login(= 1) DES> is affected too. Everything that uses PAM is affected by the need to DES> have a process wait around to call pam_close_session(). Many, but not Yes, if we want to close session, no matter PAM one, wtmp one, anyone, we need to wait session to end somewhere. I don't see any other solution here, with or without PAM. If you will have separate daemon to perform all AAA for all applications, this daemon will need to have child waiting for session e= nd. DES> all, PAM applications are also affected by PAM's reliance on callbacks DES> for user interaction (this is a major problem for OpenSSH). Performing Again, if we want to implement "any" authentication protocol (computer-human here, not computer-computer), which could include not-known-in-advance number of challenge-response-like steps, how could you solve this? You need to interact with user, in many steps. Output one string and read another one is not very hard task, IMHO. Yes, C is known for buffer overruns and things like this, but now it is common place and easy to avoid. Or you will be limited to some subset of authentication protocols, like simple password without ability to do OTP, auth e-tokens and hardware OTP calculators and such. DES> authentication in the same process that accepts and parses input from DES> potentially hostile users is also a huge security issue, cf. privilege DES> separation. Accept input from hostile user is huge security issue per se? Ouch. In modern world there are only hostile users. Yes, all our software has huge security issue, I know that :) >> And, yes, what do you mean by "fundamentally broken paradigm" here? >> PAM itself? DES> PAM, NSS, everything. Using separate APIs with separate backends for DES> identification and authentication, shoehorning modern identity databas= es DES> into the 40-year-old getpwnam() API - everything. As far as I understand, PAM is not 40-years-old getpwnam() API. It is (relative) modern API to replace getpwnam(), with support of modern identity databases in mind. Ok, maybe it is not ideal, but, IMHO, propose new one now is not realistic task. Ok, maybe PAM is not ideal (nothing is), but any API, no matter will it be self-contained library (like PAM) or library which is client to some daemon, will need to have almost same calls as PAM: authenticate user, authorize user, open session, close session... And, yes, any front-end program (like login, sshd or such) will need to call close session after user logout, and it means, it needs to have SOMETHING to call this -- forked child, thread, whatever... Also, daemon will not be able to "show" challenges to user and accept responses. Because frontend program IS one, which interacts with user. No variants. So, callbacks are unavoidable... Ok, we could have special non-privileged process to show "user interface" and sanitize (hostile) user input, it adds additional layer of protection, but authorization should be performed by privileged (root) process, as only such process could switch credentials to user's ones. I don't see how it could help with need to wait session end and why this process should call PAM by itself. And, of course, this process could not be special daemon, as it is frontend (UI) task for sure. And gain here looks to be little, especially for things like sshd, where all user input is received via well-defined protocol with packet lengths, MACs and user input is almost sanitized by this level -- only thing which could be invalid is zero bytes in text data. Do you have any examples, how this could be solved? --=20 // Black Lion AKA Lev Serebryakov