From owner-cvs-all Fri Feb 9 13:17:13 2001 Delivered-To: cvs-all@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id E581137B698; Fri, 9 Feb 2001 13:16:46 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 0ECA618C93; Fri, 9 Feb 2001 15:16:46 -0600 (CST) Date: Fri, 9 Feb 2001 15:16:45 -0600 From: "Jacques A. Vidrine" To: "Andrey A. Chernov" Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/login login.c Message-ID: <20010209151645.A20482@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , "Andrey A. Chernov" , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org References: <200102091321.f19DLoI59995@freefall.freebsd.org> <20010209184332.A47061@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010209184332.A47061@nagual.pp.ru>; from ache@nagual.pp.ru on Fri, Feb 09, 2001 at 06:43:32PM +0300 X-Url: http://www.nectar.com/ Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 09, 2001 at 06:43:32PM +0300, Andrey A. Chernov wrote: > On Fri, Feb 09, 2001 at 05:21:50 -0800, Jacques Vidrine wrote: > > nectar 2001/02/09 05:21:50 PST > > > > Modified files: > > usr.bin/login login.c > > Log: > > Fix login so that it exports environmental variables that are set by PAM > > modules (via pam_putenv). The following variables will never be set in > > this fashion: > > > > SHELL, HOME, LOGNAME, MAIL, CDPATH, IFS, PATH > > any variable starting with `LD_' > > Do you mean this is the list of _disabled_ variables? Yes, that's exactly what I mean. > All security guides recommend just opposite strategy, keeping the list > of _enabled_ variables. It prevents new and unknown evil variable > appearse unnoticed in future. That would normally apply, but PAM modules are security components -- they need to set arbitrary variables such as e.g. KRB5CCNAME (for Kerberos), and are trusted to operate correctly. Preventing `new and unknown' variables is basically counter to extensibility. The list above was garnered from the Solaris description of the interaction between pam_putenv and login. The reasoning appears to be that these are variables that login typically expects to be able to set initially. Since the Solaris documentation is the closest thing there is to a specification for PAM, I followed the example. OpenSSH's sshd, in contrast, lets the PAM modules set any environmental variable. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message