Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Feb 2002 07:07:49 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Paul Richards <paul@freebsd-services.com>
Cc:        arch@FreeBSD.org
Subject:   Re: install(1) to use a cross strip(1)
Message-ID:  <20020203070749.A25330@dhcp01.pn.xcllnt.net>
In-Reply-To: <1012779534.18110.0.camel@lobster.originative.co.uk>
References:  <20020201231306.A670@dhcp01.pn.xcllnt.net> <1012779534.18110.0.camel@lobster.originative.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 03, 2002 at 11:38:54PM +0000, Paul Richards wrote:
> > 
> > --- xinstall.c  19 Dec 2001 06:05:42 -0000      1.47
> > +++ xinstall.c  27 Jan 2002 08:54:51 -0000
> > @@ -702,6 +702,7 @@
> >  strip(to_name)
> >         const char *to_name;
> >  {
> > +       char *stripbin;
> >         int serrno, status;
> >  
> >         switch (fork()) {
> > @@ -711,7 +712,10 @@
> >                 errno = serrno;
> >                 err(EX_TEMPFAIL, "fork");
> >         case 0:
> > -               execlp("strip", "strip", to_name, (char *)NULL);
> > +               stripbin = getenv("STRIPBIN");
> > +               if (stripbin == NULL)
> > +                       stripbin = "strip";
> > +               execlp(stripbin, stripbin, to_name, (char *)NULL);
> >                 err(EX_OSERR, "exec(strip)");
> >         default:
> >                 if (wait(&status) == -1 || status) {
> 
> It's strikes me as being to risky from a security perspective.
> 
> You'd have to be really sure that there wasn't a trojan generator
> masquerading as STRIPBIN.

I've been thinking about this as well. I couldn't quite figure out
how an environment variable that allows any binary to be used as a
strip(1) alternative would be more insecure than depending on PATH
for finding where strip(1) is. In both cases the system administrator
has to make sure a known environment exists (ie known PATH vs known
setting (or absence) of STRIPBIN).

On the other hand, adding an insecure mechanism, even when not more
insecure than an existing one, will add an extra item to the check-
list and thus will increase the likelyhood of a hole...

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020203070749.A25330>