From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E7OA4-0005zu-4O for garchives@archives.gentoo.org; Tue, 23 Aug 2005 02:05:12 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7N23MZV025022; Tue, 23 Aug 2005 02:03:22 GMT Received: from www.opersys.com (opersys.com [64.40.108.71]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7N23LQP028595 for ; Tue, 23 Aug 2005 02:03:21 GMT Received: from [10.10.10.4] (dsl-136-78.aei.ca [66.36.136.78]) by www.opersys.com (8.9.3/8.9.3) with ESMTP id TAA09262 for ; Mon, 22 Aug 2005 19:38:52 -0700 Subject: Re: [gentoo-portage-dev] Re: Environment Whitelisting From: Kristian Benoit To: gentoo-portage-dev@lists.gentoo.org In-Reply-To: <430A265D.8090907@gmail.com> References: <4308E349.8010107@egr.msu.edu> <20050822035207.GA26017@phaenix.haell.com> <200508222352.13913.jstubbs@gentoo.org> <430A149D.1050907@gmail.com> <430A2453.5050008@egr.msu.edu> <430A265D.8090907@gmail.com> Content-Type: text/plain Date: Mon, 22 Aug 2005 21:57:46 -0400 Message-Id: <1124762266.6502.92.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Archives-Salt: e2bd3d83-15f9-4764-ad33-06beca9151cd X-Archives-Hash: 5b821360cd8bde01df47aa03409f9d49 On Mon, 2005-08-22 at 12:24 -0700, Zac Medico wrote: > warnera6 wrote: > >>> My preference would go 4, 3, 2 then 1. While Makefiles and configure > >>> scripts may be "broken" upstream, how long is it before the breakage > >>> goes unnoticed? More importantly, what's the chances of a dev finding > >>> the breakage before users? Cleansing the environment to me is akin to > >>> using sandbox. It offers protection against misbehaving packages... > >>> > >> > >> Good point. How about if we add environment sandboxing support (in > >> addition to filesystem sandboxing) to sandbox. With an environment > >> sandbox, we could detect specifically which variables a build is > >> fragile with regard to. The sandbox would have both filesystem access > >> and environment access violation summaries. > > > > "environmental sandbox" being similar to sandbox, or the cleansing of > > the environment? The latter is easy, the former...I am not sure how you > > begin to detect variable use in bash :/ > > > > AFAIK we can intercept getenv() calls the same way that we intercept filesystem calls. IMO the white/black/override lists would best be implemented at this level. getenv is'nt a system call. It is in the section 3 of the manual and I tried this: #include int main () { getenv("USER"); return 0; } // $ strace ./test 2>&1 | grep USER // $ strace ./test 2>&1 | grep foo # where $USER=foo and both output is empty. I have'nt checked how sandbox is working for filesystem, but filesystem related calls are at somepoint forwarded to the kernel and that is probably where sandbox is hooking. But as getenv is'nt a syscall, you could probably could probably find a way to get it to working by not linking on libc, define getenv and load libc with dlopen, but that will be a pain. As you need to libc to get your main called. Kristian -- gentoo-portage-dev@gentoo.org mailing list