Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 May 2007 20:03:10 -0400
From:      "Zane C.B." <v.velox@vvelox.net>
To:        Dan Lukes <dan@obluda.cz>
Cc:        freebsd security <freebsd-security@freebsd.org>
Subject:   Re: PAM exec patch to allow PAM_AUTHTOK to be exported.
Message-ID:  <20070520200310.4a79954e@vixen42>
In-Reply-To: <4650939B.6020004@obluda.cz>
References:  <20070519130533.722e8b57@vixen42> <86bqgfh4w0.fsf@dwp.des.no> <20070520120142.39e86eae@vixen42> <86tzu7ifp2.fsf@dwp.des.no> <20070520132410.58989605@vixen42> <4650939B.6020004@obluda.cz>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 May 2007 20:29:47 +0200
Dan Lukes <dan@obluda.cz> wrote:

> Zane C.B. napsal/wrote, On 05/20/07 19:24:
> > My current thoughts are along the lines of passing it through
> > stdin currently.
> 
> 	You can select the channel which can be used for
> information passing ? It seems you have sources of the program you
> want to call from pam_exec.

In regards to pam_exec, my interested started out towards writing a
shell script to call mount_smbfs and then possibly mounting any other
shares the user wishes and that would require their password.

Currently looking at what to do about mount_smbfs as well. I found
that it throws up the password prompt in such a manner I can pipe
the password to it.

One idea that was floated to me on the FS list the modifying it to
allow it to accept it through a socket.

Going to dig more into what is happening with piping the password to
it as well.

> 	The better way is to add a few function into sources and
> convert the standalone binary into regular pam module.
> 
> 	In the fact, the program in question:
> 1. is not PAM aware, so it can't work with PAM data without source
> code change - patch doesn't help
> 2. is PAM aware, so it shall to be written as regular PAM module -
> patch is not required
>
> 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 problem is the security
hole opened up through procfs. If it can be done safely, I see no
reason to expand pam_exec to do so as it gives it more flexibility.

In regards to writing a module for it, I am actually looking at it
given that currently I am looking at having to fix mount_smbfs and
solve this issue as well. Currently going through and beginning to
familiarize myself with the code in mount_smbfs and reading up a bit
more on C.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070520200310.4a79954e>