Date: Wed, 4 Sep 2013 00:20:38 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: freebsd-security@FreeBSD.org, Slawa Olhovchenkov <slw@zxy.spb.ru> Subject: Re: OpenSSH, PAM and kerberos Message-ID: <1289783626.20130904002038@serebryakov.spb.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1289783626.20130904002038>