From owner-svn-src-head@FreeBSD.ORG Tue Dec 1 16:29:14 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4097C106568D; Tue, 1 Dec 2009 16:29:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1499F8FC0C; Tue, 1 Dec 2009 16:29:14 +0000 (UTC) Received: from dhcp-0074221542-35-1b.client.fas.harvard.edu (dhcp-0074221542-35-1b.client.fas.harvard.edu [140.247.247.224]) by cyrus.watson.org (Postfix) with ESMTPSA id 501D746B2D; Tue, 1 Dec 2009 11:29:13 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Tue, 1 Dec 2009 11:29:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <18889B20-51A1-4B38-A303-7642AE23655B@FreeBSD.org> References: <200912010504.nB154VnS053167@svn.freebsd.org> <4B14B32C.3060409@freebsd.org> To: "Sean C. Farley" X-Mailer: Apple Mail (2.1077) Cc: svn-src-head@FreeBSD.org, Brian Feldman , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Colin Percival Subject: Re: svn commit: r199983 - in head: lib/libc/stdlib tools/regression/environ X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:29:14 -0000 On 1 Dec 2009, at 11:25, Sean C. Farley wrote: >>> We've already had two major security issues arising out of getenv.c = in the past year, and I'd like to make sure we don't have a third. >>=20 >> I think it's fair to say that the POSIXization of the environment = code has been an unmitigated disaster, and speaks to the necessity for = careful review of those sorts of code changes. >=20 > As the author of the environment code, I agree that it has been a = painful process. >=20 > Interestingly, the security issue was a combination of r169661 to = rtld.c, which is a correct action, and the new environ code which was = developed, as opposed to committed, at the same time. Separately, the = security issue would not have existed. One immediately pressing question is whether we can mitigate future = possible problems along the same lines. The obvious thing is a further = (and very careful) audit if all environmental variable use in the base = system. But I wonder if there are some other things we could do, such = as: - libc environment scrubbing: try to be more robust in the presence of = the unexpected (for example, if you find corrupted stuff, ignore it more = robustly); another variation might be to have libc abort(2) if = issetugid() and unsetenv(3) would fail. - kernel environment scrubbing: the kernel is already responsible for = getting those variables across the execve(2) boundary, so is already = copying (and to a lesser extent, validating) it, and could learn to be a = bit more rigorous in its expectations, perhaps more so for = security-sensitive transitions (setuid/setgid/MAC/...) Brian's changes, although poorly timed, seem like a reasonable direction = in this regard: we're stuck with unhelpful APIs, but maybe we can do a = better job. Robert=