From owner-freebsd-security@FreeBSD.ORG Mon May 21 00:34:38 2007 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E76F916A421 for ; Mon, 21 May 2007 00:34:37 +0000 (UTC) (envelope-from SRS0=P9Shik=KW=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout13.yourhostingaccount.com (mailout13.yourhostingaccount.com [65.254.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id A866513C45D for ; Mon, 21 May 2007 00:34:37 +0000 (UTC) (envelope-from SRS0=P9Shik=KW=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan36.yourhostingaccount.com ([10.1.15.36] helo=mailscan36.yourhostingaccount.com) by mailout13.yourhostingaccount.com with esmtp (Exim) id 1HpvKJ-0005LZ-Cl for freebsd-security@freebsd.org; Sun, 20 May 2007 20:00:39 -0400 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] ident=exim) by mailscan36.yourhostingaccount.com with spamscanlookuphost (Exim) id 1HpvKJ-0006Wo-8I for freebsd-security@freebsd.org; Sun, 20 May 2007 20:00:39 -0400 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] helo=authsmtp09.yourhostingaccount.com) by mailscan36.yourhostingaccount.com with esmtp (Exim) id 1HpvKI-0006Wc-9i; Sun, 20 May 2007 20:00:38 -0400 Received: from cpe-65-185-51-114.columbus.res.rr.com ([65.185.51.114] helo=vixen42) by authsmtp09.yourhostingaccount.com with esmtpa (Exim) id 1HpvKI-0003WE-1B; Sun, 20 May 2007 20:00:38 -0400 Date: Sun, 20 May 2007 20:03:10 -0400 From: "Zane C.B." To: Dan Lukes 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> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Zane C.B." X-EN-OrigIP: 65.185.51.114 X-EN-OrigHost: cpe-65-185-51-114.columbus.res.rr.com Cc: freebsd security Subject: Re: PAM exec patch to allow PAM_AUTHTOK to be exported. X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2007 00:34:38 -0000 On Sun, 20 May 2007 20:29:47 +0200 Dan Lukes 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.