Date: Tue, 1 Dec 2009 11:29:12 -0500 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: "Sean C. Farley" <scf@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, Brian Feldman <green@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Colin Percival <cperciva@FreeBSD.org> Subject: Re: svn commit: r199983 - in head: lib/libc/stdlib tools/regression/environ Message-ID: <18889B20-51A1-4B38-A303-7642AE23655B@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.0912011002210.68765@thor.farley.org> References: <200912010504.nB154VnS053167@svn.freebsd.org> <4B14B32C.3060409@freebsd.org> <alpine.BSF.2.00.0912011514510.84941@fledge.watson.org> <alpine.BSF.2.00.0912011002210.68765@thor.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18889B20-51A1-4B38-A303-7642AE23655B>