openssh bugs - May 2005 - [Bug 926] pam_session_close called as user or not at all

http://bugzilla.mindrot.org/show_bug.cgi?id=926


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|994                         |
              nThis|                            |




------- Additional Comments From dtucker at zip.com.au  2005-05-22 11:03 -------
I've been thinking about this.  It's too late for 4.1p1, but I think the
right
way to fix this is to split up the do_pam_setcred() and do_pam_session() calls,
and hook the do_pam_session calls into the login/logout recording in loginrec.c
(to be called from the monitor).  The existing loginmsg handling would allow any
messages returned by PAM to be sent to the user.

This would allow per-session login recording and would allow the
pam_session_close to be called from the same process as the pam_session_open. 
It would mean that pam_session_open() would not be called be pam_setcred (since
in privsep we switch to the real user very early).  I'm not sure if
that's going
to be a problem or not.

Comments (esp. from PAM folks) welcome.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=926





------- Additional Comments From t8m at centrum.cz  2005-05-23 18:59 -------
I'm not sure if I understand your proposal well so I only make some remarks
how
from the PAM point of view it should be done.

The pam_setcred(PAM_ESTABLISH_CRED) should be called before pam_open_session and
it shouldn't be necessary to call it with PAM_REINITIALIZE_CRED after that,
however it does no harm. What is important is to run pam_open_session as root
and in the same process (or before forking the child) where will be the user
shell executed.
The pam_close_session call should be done in the same process.

If your proposal stays within these limits it should be fine.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=926





------- Additional Comments From dtucker at zip.com.au  2005-05-23 19:36 -------
(In reply to comment #5)
> I'm not sure if I understand your proposal well so I only make some
remarks
> how from the PAM point of view it should be done.
Ah, but which PAM's view? :-)
> The pam_setcred(PAM_ESTABLISH_CRED) should be called before
pam_open_session
I know that's what the LinuxPAM man page says, but the Sun PAM man page says
the
opposite:

     The pam_setcred() function is used to establish, modify,  or
     delete  user  credentials.  It is typically called after the
     user has been authenticated and after  a  session  has  been
     opened.   See  pam_authenticate(3PAM),  pam_acct_mgmt(3PAM),
     and pam_open_session(3PAM).

FWIW I think the Sun approach is saner since it means that pam_setcred can drop
privs (or chroot, or whatever) and pam_open_session still has privs to write
whatever records it needs to.

[...]
> The pam_close_session call should be done in the same process.
The open+close in the same process is doable, however setcred in the same
process (or the parent thereof) as the session is a problem.  In the privsep
case, what I'm proposing is roughly this:

(monitor) forks slave
(slave) setcred(ESTABLISH_CRED), setgid, setuid
(slave) requests pty from master
(monitor) allocates pty, calls pam_open_session
(slave) forks shell process
(shell) does stuff
(shell) exits
(slave) requests session close from master
(monitor) calls pam_close_session
[connection closes]
(slave) setcred(DELETE_CRED)
(slave) exits
(monitor) exits

So, the session open/close would happen purely in the monitor, and the
establish/delete creds happen purely in the slave.

It basically boils down to this: does pam_{open,close}_session represent an
interactive (ie shell) session or an authentication session?  I suspect the
answer is "depends on the module" (which is one of the fundamental
problem with
PAM...).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=926





------- Additional Comments From t8m at centrum.cz  2005-05-23 19:58 -------
I speak about the Linux PAM.

This cannot be right in Linux PAM - you must do pam_open_session before forking
the slave process. Otherwise for example the pam_limits module will completely
fail to set the limits.

Also about the pam_setcred call - some modules may need having credentials
before opening a session - for example for mounting home directory.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.