suFirewall: Creating a Controlled Setuid Environment
People who are new to UNIX but are familiar with different
systems (e.g., VMS, MVS, etc.) typically find UNIX more
but inherently non-secure. Their opinion is often based
understanding of how controlled (or more likely, restricted)
previous OS was in comparison to UNIX. I suggest that
not be seen as a non-secure environment, but rather
a highly tailorable
environment that allows system administrators to construct
security mechanisms, protocols, and methodologies. What
I have detailed
here is a very flexible tool to aid in defining security
The key to UNIX's "openness" and/or "closedness"
within its files. To control UNIX you need to control
the most influential file type within UNIX is the directory
differs from other OSs, which usually give equal if
not higher precedence
to the files within a directory). In UNIX, if I have
read (r) and
search (x) permissions for a directory, I will be able
to read all
readable files, copy them -- at the very least obtain
listing of the file names therein. However, if I have
write (w) permission
via user, group, or other, then I can change file ownerships
file removals -- even if neither the directory nor the
to me. Ultimately, if you do not want people to manipulate
look at the contents of a directory you own, you should
permissions for group and other within the directory
mode (e.g., 700
or rwx------). But this would seem to be going from
very "open", to another, very "closed";
a UNIX security policy falls between the two extremes.
setuid programs allow certain operations to be performed
a different user within the controlled environment of
In the "good old days" of UNIX, even scripts
to be setuid. But since the PATH environment variable
is usually dynamic, setuid programs create a potential
loophole: they can be used to exploit and/or violate
of the effective user ID if PATH is reset so that executables
within the script would point to executables on the
The now ancient solution to this problem was to fully
executable path names within the setuid script. This
ugly solution in that it depended upon the discipline
of the programmer
to assure that directly and indirectly called executables
qualified path names. Most UNIX systems do not allow
scripts anymore (DGUX 4.x was the last one I knew of).
UNIX shell script is an excellent rapid prototyping
has made it more difficult to build powerful setuid
in a short period of time.
A helpful UNIX utility would be a sort of "firewall"
program execution -- including scripts. One example
of an application
where this suFirewall could be used is with source code
By using setuid front ends to the source code control
in SCCS, you could hide the actual s-files from the
Other examples may include giving restricted access
to root level
commands or the setting up of a secured login environment
What I describe here is a secure process for creating
programs -- scripts or binary executables. This process
work for any SVR4 UNIX as well as most UNIX derivatives
Making Directory and File Structures
Two directories (at least) are necessary to the secured
environment. The first directory, the Secured Directory,
the executable files where only the effective user has
second directory, the Public Directory, contains the
program as well as the interface stubs which determine
Directory commands may be executed.
Create the Secured Directory with the owner set to the
id you wish to exploit (e.g., suser). Set the permissions
on the directory
to 700, so that only the owner can examine or make changes
to files contained there. Within this directory, place
all of the
executables that need to execute as the effective user
as well as
any other files referenced by the executables (e.g.,
files). Do not set the setuid bit on the executables:
will do this.
To force even the owner of the Secured Directory to
use the suFirewall
access interface, you may want to optionally prefix
or suffix the
executables with a string of your own choosing. This
accidental bypassing of the suFirewall interface (for
when dot (.) has precedence in your PATH). The suFirewall
access interface will use the name of the stub file
found within the
Public Directory and will create the name of the actual
by prefixing or suffixing your special character string.
You can use
non-printable characters for your prefix or suffix;
I prefer this,
since it makes it even more difficult to accidentally
invoke the Secured
The Public Directory (e.g., /usr/local/bin) will have
such that all users of the suFirewall interface can
the "stub" files located there. Each "stub"
a symbolic link to the suFirewall program. The "stub"
file name is the name of the Secured Directory executable
the optional suffix or prefix. The suFirewall program
reside here, but if users have write permission to the
(thus the ability to delete/replace the suFirewall),
prefer to place it in a directory that doesn't allow
access. In addition, suFirewall itself may only have
permission for members of a particular UNIX group. Figure
how the resulting directory structure might look.
Making the suFirewall Program
As mentioned earlier, all the "stub" files
are symbolic links
to the suFirewall. The actual suFirewall executable
uses the basename of argv plus any optional prefix
or suffix characters (known only to suFirewall) to determine
which program in the Secured Directory to execute.
All of the executable programs and scripts are funneled
setuid executable (suFirewall will do an execvp,
among other things). Listing 1 shows full source for
program. Below are the general steps to follow in coding
1. Reset the PATH to the standard path for the platform.
2. Prepend to this PATH the path(s) where your secured
and scripts will reside. Use putenv to modify PATH
in the environment.
3. Take the basename of argv as the name of the
secured program desired. Optionally, prefix or suffix
characters to the newly formed Secured Directory program
refer to the resulting program name as secured_name.
4. Use putenv to place anything else you want into the
5. Perform an execvp(secured_name, argv).
6. Compile the program and turn on the setuid bit for
7. Place the program in a directory area which is searchable
is on the PATH of the users of the Secured programs.
Drawing "Effective" Conclusions
Since the suFirewall actually controls the user's environment,
the user cannot simply alter his/her PATH to circumvent
Also, the user is completely isolated from the source
used by the suFirewall, to the extent that he/she does
know if a binary or a script is really being executed.
Doing a ps while a secured shell script program is running
will show the shell being invoked with the secured_name
its first argument. If you find this too revealing,
then you could
execvp a shell directly with argv set to whatever
name you want in order to better hide the fact that
you are using
a shell script. This strategy, however, incurs the undue
of invoking a shell to execute binary files.
You could also put an executable in the Secured Directory
to the name of the suFirewall program itself. This program
could be used to perform real work.
Sometimes within a setuid program, you will need to
back to your real user id. For example, your own file
may be such that you cannot access the files under another
(this is especially true for AIX users, see the sidebar
Within a C program, reverting to the real user id is
a trivial call
to setuid. Doing the same from a script, however, requires
using a separate program. Call the program realdo from
your secured scripts to execute commands as the real
of as the effective user. Listing 2 shows realdo.c.
As I mentioned earlier, source code control is an excellent
ground for suFirewall. Normally in SCCS, the s-files
(delta files) are read accessible (mode 444) and found
in a searchable
directory (mode 755). This means that only the SCCS
toolset can manipluate
the s-files and only the owner of the s-files can
use administrative commands. However, if you have customized
files are manipulated by writing scripts around the
commands, might not want people to access the s-files
the normal SCCS commands.
One solution is to make the directory for the s-files
only by the effective user (e.g., suser) of suFirewall.
This way, only the suFirewall command set can manipulate
files. The effective user can still do the SCCS commands
owns the s-files), but this is generally acceptable.
I also mentioned earlier the possibility of using configuration
within the suFirewall commands. You could for instance,
in a file of local/environment variables that could
be used within
the suFirewall scripts to locate the s-file area,
perform extra security measures, or define commonly
across all suFirewall scripts.
Listing 3 contains the source for a script which will
do a get
-e (check out) of a file. Listing 4 sets some variables
you to locate where the s-files reside, what release
are locked down, and some shell functions.
UNIX can be a very secure operating environment as long
as you know
the secrets of security. Avoiding setuid scripts is
a solution to setuid "backdoors." I hope that
will help you to perform rapid prototyping, if not full-scale
using UNIX scripts.
About the Author
Chris Cox is a Computer Science graduate of Texas A&M
with an Electrical Engineering minor. He has been working
since System III, and over the past ten years has been
developer, configuration manager, porting engineer,
and system administrator
for heterogeneous UNIX environments. Chris is currently
a configuration manager by CARE Systems Corporation,
Dallas, TX. He
can be reached via email at Chris_Cox@ps.net.