From owner-freebsd-security@FreeBSD.ORG Sun May 20 18:23:44 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 B835816A46F for ; Sun, 20 May 2007 18:23:43 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4]) by mx1.freebsd.org (Postfix) with ESMTP id 48B5F13C46C for ; Sun, 20 May 2007 18:23:43 +0000 (UTC) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from kulesh.obluda.cz (openvpn.ms.mff.cuni.cz [195.113.20.87]) by smtp1.kolej.mff.cuni.cz (8.13.8/8.13.8) with ESMTP id l4KI6Khg023706 for ; Sun, 20 May 2007 20:06:21 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <46508E1B.8030302@obluda.cz> Date: Sun, 20 May 2007 20:06:19 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070327 SeaMonkey/1.1.1 MIME-Version: 1.0 To: FreeBSD Security References: <20070519130533.722e8b57@vixen42> <86bqgfh4w0.fsf@dwp.des.no> <20070520120142.39e86eae@vixen42> <86tzu7ifp2.fsf@dwp.des.no> In-Reply-To: <86tzu7ifp2.fsf@dwp.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Sun, 20 May 2007 18:23:44 -0000 Dag-Erling Sm=C3=B8rgrav napsal/wrote, On 05/20/07 19:10: > "Zane C.B." writes: >> Dag-Erling Sm=C3=B8rgrav writes: >>> Your patch opens a gaping security hole. Sensitive information >>> should never be placed in the environment. >> Unless I am missing something, this is only dangerous if one is doing >> something stupid with what ever is being executed by pam_exec. >=20 > Environment variables may be visible to other processes and users > through e.g. /proc. Many sensitive informations can be accessible via /dev/kmem but the=20 default mode of the device doesn't allow regular user access. We trust the responsible administrator he doesn't load the mem.ko=20 module and change the mode/ownership of /dev/kmem the way that open a hol= e. So we shall trust the same administrator he doesn't load the procfs.ko=20 and mount /proc creating the security hole this way. Please note I agree with the conclusion - the offered patch shall be=20 rejected. I disagree with explanation only. It's not as simple as=20 presented. Dan --=20 Dan Lukes SISAL MFF UK AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz