PAM exec patch to allow PAM_AUTHTOK to be exported.

[Zane C.B.]

On Mon, 21 May 2007 03:43:22 +0200

3. want's to be PAM aware, but it's programmer is too lazy to
write it the clean way (as regular pam module) - we need the
patch
The patch shall be rejected because the only purpose of
it is to support lazy programmers creating hacks instead of
solutions.

Actually it does not support lazy programming, but makes life of a
makes life of a administrator easier.

The contrib/smbfs/mount_smbfs/mount_smbfs.c is very short
and simple. Writing PAM module with same functionality require
almost the same amount of time as patching it. In advance, you need
catch not only pam_sm_session_open but pam_sm_session_close (i
assume you plan to umount resource also). Unfortunately (unless I
miss something) pam_exec has no way to pass about 'direction' to
called program. You can't use simple heuristic "when not mounted
mount it and vice versa" also because the same user can have more
than one simultaneous active session.

True. That would be another issue. Regardless, it is going to need a
daemon to run in the background or something. I don't think using PAM
to figure out if it should be unmounted is a good idea, unless you
kill all processes owned by that user upon session close. IMO it
would be best to check if there are any processes running owned by
that user before unmounting it and if there are, leave it for the
cleanup daemon.

The logic you need to implement seems to require much more
coding than simple patch on either pam_exec nor mount_smbfs ...
pam_exec in chain more hurts than helps. IMHO, of course.
But further discussion about it seems not to be security
related, so we should not continue here.

Yup. Moving to hackers. :)

[Dan Lukes]

Post by Zane C.B.

In advance, you need
catch not only pam_sm_session_open but pam_sm_session_close (i
assume you plan to umount resource also). Unfortunately (unless I
miss something) pam_exec has no way to pass about 'direction' to
called program. You can't use simple heuristic "when not mounted
mount it and vice versa" also because the same user can have more
than one simultaneous active session.

True. That would be another issue. Regardless, it is going to need a
daemon to run in the background or something.

In the fact, you are in trouble because the OS doesn't know "user
session" so it didn't help you to maintain the information. User session
is PAM category.

You are true - you need a system-wide persistent object that hold
information "a session for user X remain active". You can create a
daemon, you can create a file in the filesystem or so. But it's not
solution of your main problem - where to catch information the session
start/ends.

At the first, you have with session start whenever PAM not used for
authentication. It's not only telnetd which doesn't use PAM at all.
There are many daemons that can start user-scripts but not as part of
(PAM) user session. For example CRON, SENDMAIL (when "| script.sh" used
in .forward) and so on.

Even worse is catching of session-end. At the first, it's application
responsibility to call PAM's session close and the close may not be
called in some cases of abnormal end. Even if we ignore those abnormal
cases, regular exit of the application authenticating the user into
system constitute end of PAM's session, but it doesn't mean that no user
proces is running in the system. There are may be tenths of proceses
started during session that run in the background, detached from
terminal and owned by INIT as parent process.

To make things more complicated, a process can have more than one
effective user during lifetime. If euid chages - are you ready to remap
directories accordingly ?

Post by Zane C.B.
I don't think using PAM to figure out if it should be unmounted is a good idea

In the fact, I don't thing the PAM is good place to figure out the
directory needs to be mounted as well.

PAM may be the place where you can stealth the user name and password
an store it somewhere for later use.

You can create kernel module monitoring process creation and EUID
changes. It can map/unmap user's directories.

Unfortunately, you need secure persistent storage of every user name
and password (user processes may be started shortly after the start of
system - before the user log-in first time, so in-memory only storage is
not sufficient).

By the way, we still speak about "name+password" authentication only.
Your system can't work when user authenticate itself by other system
(digital signature, OTP, challenge-response, magnetic or chip card, a
biometric based authentication and so on).

If your system allow access via ssh and a user will use authentication
wia key, then you have no way to do what you want automagicaly.

Even if we forget other authentication system than "name+pwd",
persistent password database is security risk. Persistent storage of
user credentials without it's approval may have law consequences also.

If we speak about proprietary solutions (for your only) it may not be
problem. If we speak about "standard distribution solution" we can't
forged about it.

Post by Zane C.B.
unless you kill all processes owned by that user upon session close.

Insufficient. Process with effective rights as a user can be started
later, not as a part of a session. You need global knowledge about all
processes and their efective UIDs.

Post by Zane C.B.
IMO it
would be best to check if there are any processes running owned by
that user before unmounting it and if there are, leave it for the
cleanup daemon.

"Cleanup daemon" is "end-session" solution. Not "start-session". You
need kernel module for "is a process runing for a user" tracking. PAM
may help with creating persistent system password database used by this
module for real mounting.

Or you can reevaluate what you want. If you need "automagic mouting"
avaiable during interactive user sessions only then things become simpler.

Post by Zane C.B.
Yup. Moving to hackers. :)

I'm not a member.

Dan