From owner-cvs-all Sun Feb 11 19:27:33 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AEDC937B401; Sun, 11 Feb 2001 19:27:23 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1C3RJh82272; Sun, 11 Feb 2001 22:27:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 11 Feb 2001 22:27:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garance A Drosihn Cc: Kris Kennaway , Jacques Vidrine , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, security-officer@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/login login.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Feb 2001, Garance A Drosihn wrote: > At 12:17 PM -0800 2/9/01, Kris Kennaway wrote: > >On Fri, Feb 09, 2001, Jacques Vidrine wrote: > > > > >> 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_' > > > >This isn't a complete list of insecure environment variables, if > >that's what it's trying to be. I would feel much happier making > >this a defined list of allowed variables so we don't have obscure > >security fallout from it. > > Where would the list be defined? > Would it make sense for it to be settable via /etc/login.conf? Perhaps I'm confused here, but isn't the list above the list of environmental variables being applied to environmental variables exported by the authentication/login authorization system itself? I'm a bit confused as to why those variables even need filtering, other than to discourage module developers from colliding on use of these potentially abused variables. More on your point, however -- having a centralized list of "safe" variables, possibly classifiable by user class, would be nice. However, a lot of the places where this list of variables is needed are places where a user class is not available -- for example, in the telnetd->login transition. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message