This is version 5.1 of my su1 program. It compiles without any problems under a recent Linux, and should work on most other UNIX systems with only minimal changes.
- FILES
README This file Makefile To build su1 (assumes gcc) su1.c Source file for su1 su1.1 Man page for su1 su1.pam Sample PAM file for su1 su1.priv Example privilege file (requires customization)
- FEATURES
Su1 allows selected users to run selected commands as root (or other users) based on a privilege file which is editable, easily understandable, and versatile. The privilege file is read line by line to find directives which change the internal state of su1. When a line is found which allows the user's command to be executed, then the current state is used for that command. In this way, many different combinations of the available features can be configured.
There are two ways to determine user's privileges:
. The user's user name
. The user's list of group names
There are five types of allowed commands:
. Only the exact command line is allowed
. Optional arguments can be added after an exact command line
. Optional arguments not beginning with dashes can be added
. A single optional argument not beginning with a dash can be added
. Any command can be executed
There are three methods of requiring passwords:
. A password is never required
. A password is always required
. A Password is required only if not given recently in the session
There are four ways to log commands:
. Successful commands can be logged into log files
. Successful commands can be logged to syslog
. Failed commands due to bad passwords can be logged to syslog
. Refused commands that are not allowed can be logged to syslog
Validation of the root password can be defined at compile time to use:
. The root password from /etc/password
. PAM (Pluggable Authentication Modules)
Lists of users and groups can be defined so that sets of users can be easily used throughout the privilege file.
User names can optionally consist of two components separated by a period. These components are a user name and a group name, both of which must match before allowing access to a command. Each component can contain wildcard characters to match related names. For example, "dbell" matches the user name "dbell" in any group, and "*.admin" matches any user in group "admin".
Different passwords can be specified to protect different combinations of commands and users. The passwords can either be the real root password or else the specified (encrypted) passwords.
The time interval for requiring passwords can be specified depending on the command and user, so that innocent commands can have a longer time interval than destructive commands before requiring a password. Extremely dangerous commands could always require a password.
A user can quickly expire his password interval so that he can leave his terminal for a few minutes without worrying about another user walking up and executing privileged commands without a password.
Command aliases can be defined so that you can create your own special commands that expand into the actual commands. For example, "cdmount" might expand into "mount -t iso9660 /dev/cdrom /cdrom -o ro".
Links can be made from su1 to commands with the same name as aliases, and executing su1 using those commands will execute the aliased commands. Thus if "cdmount" had been aliased as above, by linking su1 to cdmount you can simply type "cdmount" to execute the command.
The search path used for running commands is configurable. The search path is used even when the user is trusted to run any command so as to prevent accidental running of programs from untrusted places. (Trusted users are still allowed to run any program by explicitly specifying its path.)
A configurable set of environment variables can be specified which are allowed to be sent down to the command being executed. All other environment variables are removed to help avoid security problems.
Specific users or groups can be refused access to commands as desired.
The command to be executed can be run as any user or group id.
- INSTALLING
Become root.
Determine whether or not you want to build su1 to use PAM. Edit the Makefile and choose the appropriate pair of PAM-related defines to use. The default in the Makefile has PAM enabled.
Determine whether or not you want to use the getsid system call. If your system supports this call then you should use it. Edit the Makefile and choose the appropriate pair of GETSID-related defines to use. The default in the Makefile has GETSID enabled.
Build su1 by typing "make".
Copy su1.1 to your man page directory, such as /usr/local/man/man1.
Copy su1 to your bin directory, such as /usr/local/bin.
Chown su1 to root and protect it 4511 to make it executable and setuid root.
Create a /etc/su1.priv file containing your allowed commands and chown it to root and protect it 400 to make it readable only by root. You can use the supplied su1.priv file as a guide, but DO NOT just copy it in without modification since it will not work.
Or alternatively, do "make install" and then edit the /etc/su1.priv file as required. The install creates an empty privilege file if necessary, but won't modify an existing one, so it isn't dangerous to run again.
If PAM is being used, add su1 to the list of programs approved by PAM. To do this either edit /etc/pam.conf or add an su1 file in the /etc/pam.d directory (whichever is appropriate for your system). A simple PAM file for su1 is supplied as su1.pam. If the configuration in this file is acceptable, you can type "make install-pam" to copy su1.pam into /etc/pam.d/su1.
Create hard or soft links from su1 to the command aliases defined in your /etc/su1.priv file that you wish to be runnable directly by users. This saves them the trouble of typing "su1" before the command.
That's it!
David I. Bell
dbell@canb.auug.org.au
September 29, 2002