PROMAIN(M) UNIX System V
Name
promain, nopromain - restrict the execution domain of a
program
Syntax
auths -r nopromain
Description
The promain feature allows you to control the damage an SUID
program can do to your files. An SUID program starts
execution with effective user ID equal to the owner of the
SUID program file and real user ID equal to the invoker of
the SUID program. On traditional UNIX systems, an SUID
program has complete access to all files, processes, and IPC
objects (collectively called resources ) to which the
invoker or the owner has access, because the program can use
setuid (S) to switch between the invoker and owner user ID.
Outside a promain, this power is restricted to resources to
which the invoker and the owner have access, as described in
this section.
The SUID feature is used when one user (or system function)
needs to protect files from access except through a well-
defined set of programs. An example is the suite of line
printer commands, which work with a set of configuration
files, status files, and shell scripts to keep track of
which print jobs are queued to which printers. Users and
line printer administrators use several commands to submit
and cancel jobs, change and query the status of printers,
and add and remove printers from the system or from active
duty. All printer files are owned by the pseudo user lp ,
the user ID which is the owner of all files used by the line
printer subsystem, including the printer special devices
themselves.
When you invoke the lp (C) command to print a file, the
program can access the files in the database, but can also
access files that you request to be printed because the
program can setuid to your user ID to access your files. A
malicious lp program could just as easily look for protected
files in your directory hierarchy and copy them to a place
protected such that only lp could read them. Thus, the fact
that you trust lp enough to run it as a program means that
you trust that it will not abuse the power you give when you
run it.
If you run a SUID program on a trusted system and the
promain kernel authorization is off , a promain is created,
and the current directory is noted as the promain root .
Files in the subtree starting at the promain root are said
to be inside the promain, while files outside that subtree
are said to be outside the promain. Promains protect a user
against a malicious SUID program by restricting the kinds of
accesses the program can do outside the promain when running
as you (the invoker). When running with the invoker's
effective user ID outside the promain, the program can
access files if both the invoker and the owner have access
(public files). Inside the promain, the program has access
according to the rules associated with normal UNIX systems.
To run untrustworthy SUID programs with promain protection,
do the following:
1. Start a subshell without the nopromain authorization,
as in this example:
$ auths
Kernel authorizations:
nopromain,execsuid
$ auths -r nopromain
$ auths
Kernel authorizations: nopromain
2. Change directory to one in which you will place all
files which you expect the program to modify, and put
all the files the program needs there, as in the
following example:
$ cd tmp
$ cp path/file1 path/file2 .
$ ls -ld . file1 file2
total 10
drwxrwx--- 2 drb mktng 64 Jul 30 07:53 .
-rw-rw---- 1 drb mktng 10345 Jul 30 07:52 file1
-rw-rw---- 1 drb mktng 9200 Jul 30 07:52 file1
$ pwd
/usr/drb/tmp
3. Run the program. In /usr/drb/tmp , the program has
complete access to file1 , file2 , and the /usr/drb/tmp
directory. Assuming that all files owned by drb
outside the /usr/drb/tmp directory are protected, the
program has access only if drb allows public access.
Note that promain protection is enforced for all system
actions outside the promain when running under the effective
user ID of the invoker. The program cannot read or write
files unless they are accessible to the program owner and
the invoker. The program cannot use chown(S) or chmod(S) on
files outside the promain as drb because drb and the SUID
program owner cannot possibly both own the file unless drb
is the program owner as well. In addition, the program
cannot link files outside the promain to a file inside the
promain unless the file is accessible to bot the invoker and
the owner. This protects against a malicious program
getting around promain protection by changing the search
path used to access the file.
What Promains Guard Against
Promains were designed to guard against one specific type of
Trojan Horse attack, where another user supplies you with a
SUID program which steals some of your files into a location
or directory to which you do not have access. It also stops
the common case of creating a program which is SUID to your
user ID by using setuid(S) to:
1. Set the program's effective user ID to you (the real
user ID),
2. Create a file (which sets you as the owner), and
3. Change the program's mode such that the SUID bit is on.
Promains stop these attacks by only allowing file creation
if both the invoker and the program owner are allowed an
action. Thus, the program will only be able to access your
public files (world or group readable) and will never be
able to use the SUID attack to create a malicious program
(e.g., a shell) which is SUID to you. If your file
hierarchy is suitably protected, you can stop attempts to
steal data or create damaging files (e.g., programs which
have the same name as system programs which you execute
because you have included the current directory in your
search path).
What Promains Do Not Guard Against
Promains do not protect against running a SUID program which
has access to public files or directories in your
hierarchies. Neither do they protect against Trojan Horses
which are not SUID. A program which is not SUID is
effectively given access to any objects to which you have
access. Thus, running a program which you do not trust is
in effect giving your entire discretionary capability to
that process. Always suspect a program which is given to
you from someone whose motives you have no reason to trust.
The newspapers today are full of stories of Trojan Horses
and computer viruses (one special case of a Trojan Horse)
which were planted by someone who was able to arrange for a
user to run a program which did something malicious.
See Also
auths(C), ``Maintaining System Security'' in the System
Administrator's Guide
(printed 8/23/89) PROMAIN(M)