Date: Sun, 20 May 2007 20:06:19 +0200 From: Dan Lukes <dan@obluda.cz> To: FreeBSD Security <freebsd-security@freebsd.org> Subject: Re: PAM exec patch to allow PAM_AUTHTOK to be exported. Message-ID: <46508E1B.8030302@obluda.cz> In-Reply-To: <86tzu7ifp2.fsf@dwp.des.no> References: <20070519130533.722e8b57@vixen42> <86bqgfh4w0.fsf@dwp.des.no> <20070520120142.39e86eae@vixen42> <86tzu7ifp2.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Sm=C3=B8rgrav napsal/wrote, On 05/20/07 19:10: > "Zane C.B." <v.velox@vvelox.net> writes: >> Dag-Erling Sm=C3=B8rgrav <des@des.no> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46508E1B.8030302>