Date: Mon, 12 Feb 2001 07:27:56 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Robert Watson <rwatson@FreeBSD.org>, Garance A Drosihn <drosih@rpi.edu>, arch@FreeBSD.org, security-officer@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/login login.c Message-ID: <20010212072756.A39882@hamlet.nectar.com> In-Reply-To: <20010211193432.A5428@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 11, 2001 at 07:34:32PM -0800 References: <p05010415b6ad05de601a@[128.113.24.47]> <Pine.NEB.3.96L.1010211222430.64780Q-100000@fledge.watson.org> <20010211193432.A5428@mollari.cthul.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 11, 2001 at 07:34:32PM -0800, Kris Kennaway wrote:
> On Sun, Feb 11, 2001 at 10:27:19PM -0500, Robert Watson wrote:
>
> > 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.
>
> Yes, this has been clarified, although I still worry about a PAM
> module passing in environment variables from the remote system
> somehow.
This is easy to check:
1) It is a bug for a PAM module to call `putenv' or `setenv'.
2) If a PAM module wishes to modify the environment, it notifies
the application by caling `pam_putenv'. [1]
It's simple to audit a PAM module for these cases. Note that none
of the modules in our base system modify the environment. The only
module that I know of that modifies the environment is pam_krb5 --
it sets KRB5CCNAME (via pam_putenv, of course).
> > 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.
>
> Yes, we need a way for the administrator to add environment variables
> which are safe or desired in the local environment. Recently telnetd
> was changed to filter out all but a set of known safe variables, so
> the only way for an administrator to do this would be to recompile
> telnetd.
[this more or less directed at the comment about restricted variables
determined by user class]
I'm skeptical. It is up to the application that is granting
priviledges to decide what is safe in the environment. e.g.
sshd might set SSH_* stuff; sshd, telnetd, login might set KRB5CCNAME;
xdm might set DISPLAY, XDM*; who knows what else may come down the line.
Such trusted applications must be audited anyway.
Cheers,
--
Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org
[1] It is this list of environmental variables that my commit `filters'.
For the convenience of archive users, I'll restate here that the
`filter' is present merely to duplicate the behavior of Solaris
login/PAM interaction. Previous to my commit, _no_ variables were
exported -- which was a bug.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010212072756.A39882>