From owner-svn-src-head@FreeBSD.ORG Tue Dec 1 16:46:59 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 CB58E106566C; Tue, 1 Dec 2009 16:46:57 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 7672E8FC14; Tue, 1 Dec 2009 16:46:57 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.3/8.14.3) with ESMTP id nB1GkuWG044128; Tue, 1 Dec 2009 10:46:56 -0600 (CST) (envelope-from scf@FreeBSD.org) Date: Tue, 1 Dec 2009 10:46:56 -0600 (CST) From: "Sean C. Farley" To: "Robert N. M. Watson" In-Reply-To: <18889B20-51A1-4B38-A303-7642AE23655B@FreeBSD.org> Message-ID: References: <200912010504.nB154VnS053167@svn.freebsd.org> <4B14B32C.3060409@freebsd.org> <18889B20-51A1-4B38-A303-7642AE23655B@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org 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:47:00 -0000 On Tue, 1 Dec 2009, Robert N. M. Watson wrote: > On 1 Dec 2009, at 11:25, Sean C. Farley wrote: > >>> 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. >> >> As the author of the environment code, I agree that it has been a >> painful process. >> >> 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. The preliminary patch I sent earlier should at least make the calls behave more like they used to do (go through each variable even if corrupt). However, I do agree that more code (getenv.c and any code that calls into it) needs to be verified for more paranoid use of the environment. As for abort(), I was/still am considering having that be the result of a corrupt environ array. If it is corrupt, why attempt to use it? unsetenv() may still fail, so it may not abort() for other scenarios. > - 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/...) That is a good point. I had not thought about kernel validation of the environment in addition to the validation performed in libc. > 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. Getting rid of putenv() and especially removing direct access of environ (replaced with API call(s)) would be my favorite API changes. Sean -- scf@FreeBSD.org