OpenSSH, PAM and kerberos

[Lev Serebryakov]

Hello, Dag-Erling.
You wrote 3 сентября 2013 г., 19:25:11:

DES> I am *not* proposing to move PAM into a daemon.  I am proposing
DES> something completely new.  I thought I made that clear.
  I totally agree with Dmitry Morozovsky's words, so, please, don't read
 my words as arguing with you, but rather as questions

  I try to write some short list of requirements to this completely new
 solution, where am I wrong? I'm sure, I am, but, where? Thank you.

  (1) It should support loadable backends from very beginning, or we will
  end with NSS-like hacks and kludges (yes, I'm totally agree with you, that
  NSS is ugly hack).

  (2) It should run most of backends with dropped privileges -- you don't
  need to be "root" to connect to LDAP or KRB server, for example, and
  better do this from restricted account.

  (3) It should be able to run SOME PARTS of SOME backends with super-user
  privileges, as one of backends should be able to read system password
  (shadow) file, as we want to support good old /etc/master.passwd.
  pam_ssh-like backend need to read user's private key, too.

  (4) It should support "partial" backends, which doesn't support all AAA
  functions. One backend could be used only for authentication (like
  pam_ssh) and other for identity management (like LDAP without
  authorization). So, complete feature set could be obtained from SET of
  backends, not only one backend in time (it looks hard to do properly and
  flexible enough).

  (5) It should be able to run some backends parts (callbacks?) after
  switching privileges to authenticated user. For example, kerberos backed
  should be able to store credentials file in user home directory with user
  access rights. Backends should be able to communicate to core of daemon to
  specify which parts should be run with which privileges. Again, it doesn't
  look easy to do properly.

  (6) It should provide channel for backend to pass any information from one
  privilege domain to other one, as kerberos backend should be able to pass
  ticket from restricted domain (where kerberos protocol is implemented) to
  user or superuser domain (to store in file in user direcotory).

  (7) It should provide some API for challenge-response like converstation
  with user.

  (8) It should provide some API for session tracking for accounting and
  some way for backends to clean-up at session end (it is most questionable
  part, IMHO, as it hard to do without zillions of sleeping processes when
  users are logged-in).

  (9) "old" API should be mapped to this daemon, instead of NSS, as we have
  multitude programs in ports, which doesn't know about this new API (ouch,
  I don't like this part).

  (10) Many backends should be re-implemented from NSS or PAM API (and I
  don't like this one too). Generic wrappers for NSS and/or PAM modules
  looks complicated and, again, is the same "crap" as NSS and PAM
  themselves.

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