OpenSSH, PAM and kerberos

[Lev Serebryakov]

Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 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 end.

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 databases
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?

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>