Re: [gentoo-portage-dev] Re: Environment Whitelisting

[Kristian Benoit]

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 <unistd.h>

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@g.o mailing list