Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Feb 2001 22:27:19 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        Kris Kennaway <kris@obsecurity.org>, Jacques Vidrine <nectar@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, security-officer@FreeBSD.org
Subject:   Re: cvs commit: src/usr.bin/login login.c
Message-ID:  <Pine.NEB.3.96L.1010211222430.64780Q-100000@fledge.watson.org>
In-Reply-To: <p05010415b6ad05de601a@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010211222430.64780Q-100000>