Sidebar: Security Issues
Programs that launch pipelined tasks pose potential
security problems
because they open the possibility of a system intruder's
substituting
an unauthorized program of the same name for one of
the pipeline's
component programs. For example, an unauthorized program
could be
named who and placed on the path so that it gets executed
in
place of the standard who.
To write absolutely secure C programs using pipes, always
use the
absolute path to the command(s) to be executed, i.e.,
never search
the PATH. The pipe() method will not search the PATH
so long as communicating tasks are launched with execl(),
execv(),
execle(), or execve(). The other two members of the
exec() family of functions, execlp() and execvp(),
as well as popen() and system() do search the PATH.
While completely ignoring the PATH is too restrictive
for most
serious applications, there are coding practices that
do improve security
without sacrificing the use of the PATH:
1. Always make sure the PATH is set to search the system
directories
first. Never search the current directory first, especially
the root
user. Always make sure the command being executed is
the one you really
want to execute. In particular, you should never use
a path
like:
PATH=.:/bin:/usr/bin
which searches the present directory first.
Programs that use popen() can enforce this restriction
by setting
the PATH before executing the command(s) to be piped:
char *com_str="PATH=/bin:/usr/bin; who|sort|pr";
This prevents a user from tinkering with the PATH even
if shell
access is possible.
2. Avoid calling programs that can escape to the shell.
At the very
least, these programs allow an intruder to shell out
and change the
PATH to search directories other than the system directories
first. This change alone, is enough to allow the intruder
to force
an unauthorized version of a system command to be executed.
3. Avoid setting the user ID on executables, especially
on executables
owned by root. Setting the user ID bestows the file
owner's permissions
and not the permissions of the user executing the file.
Consider the
example executable, test:
-rwx--x--x 1 root usr test
Suppose test tries to read the data file datafile:
-r-------- 1 root usr datafile
User root owns test and if user steve tries
to execute test, a read error occurs, because steve
doesn't have permission to read datafile. After setting
the
user ID with the chmod u+s command:
-rws--x--x 1 root root test
Now if user steve executes test, datafile
can be read with no errors. At the very least, user
steve could
affect the datafile if shell access is possible.
|