[ On Thursday, October 31, 2002 at 17:15:00 (-0500), Roland Dowdeswell wrote: ]
> Subject: Re: verified executable kernel modification committed 
>
> 
> You can always provide absolute paths for executables to run.  What
> I was suggested was not that someone can inject a binary into your
> path, but rather execute non-trusted code from an arbitrary location.
> I do not see how the setting of PATH would affect:
> 
> 	$ /u/elric/mybinary

Hmmm... yes, well there's the perhaps not-so-obvious answer that I left
out -- you implement the old "restricted shell" features by replacing
/bin/sh with a hard link to /bin/ksh and adding another hard link to
/bin/rksh and then forcing everyone to use /bin/rksh as their shell.
Then no path (absolute or relative) is allowed on any shell command.

And you take away the compiler and anything else that can invoke another
program without forcing use of $PATH.....  :-)

Once a long time ago I thought a bit about the idea of implementing a
second environment array, but this one being read-only env variables and
then fixing all things like shells and library calls to effectively
enforce a global read-only $PATH and similar.  That way so long as you
could be sure no unauthorised code existed that called execve(2)
directly then in conjunction with a restricted shell you'd be able to
really control what could be run by any user, even root.  Back then the
lack of open source hindered my idea almost completely.  Even today with
full system sources at my disposal I'm not sure there's enough benefit
to such an idea, and especially not now with verified exec.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>