From owner-freebsd-arch Mon Feb 12 5:28: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 9B10B37B401; Mon, 12 Feb 2001 05:27:57 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 6B52218C93; Mon, 12 Feb 2001 07:27:56 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1CDRuI39934; Mon, 12 Feb 2001 07:27:56 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 12 Feb 2001 07:27:56 -0600 From: "Jacques A. Vidrine" To: Kris Kennaway Cc: Robert Watson , Garance A Drosihn , arch@FreeBSD.org, security-officer@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/login login.c Message-ID: <20010212072756.A39882@hamlet.nectar.com> References: <20010211193432.A5428@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010211193432.A5428@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 11, 2001 at 07:34:32PM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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