Distributing root Privileges: Part 1 of 2: SUID Scripts, sudo, and Restricted SAMBy Chris Wong
In UNIX, the process of distributing tasks is more complicated compared to other operating systems. In UNIX there are basically two classes of users: a regular user and the root user. A regular user is limited to performing tasks and running applications by the permissions assigned to files and directories. On the other hand, the root user can do whatever they please. This is great if you are an experienced system administrator but what about tasks that need to be performed by the junior administrator or the operator? Backups, user management, and other repetitive tasks are often delegated to personnel that should not have root access. The problem is that without root access, they won’t be able to perform the assigned tasks.
This has led to various ways of giving the
non-root user the necessary authorizations to perform tasks requiring root
access. Table 1 displays the five methods for
distributing root privileges that are covered in this and next month’s article.
|
Tools č |
SUID Scripts and Programs |
sudo |
Restricted SAM |
SCM |
OpenView Operations |
|
Supported by
HP |
No |
No |
Yes |
Yes |
Yes |
|
Cost |
Your time |
Free |
Free |
Free |
$$$$ |
|
Integrated
with HP Tools |
No |
No |
Yes |
Yes |
Yes |
|
Available
Interfaces |
Command Line (CL) |
CL |
GUI or CUI |
CL, GUI or Web |
GUI or Web |
|
Auditing |
You write |
Yes |
Yes |
Yes |
Yes |
|
Linux
Support |
Yes |
Yes |
No |
Yes |
Yes |
|
System
Resources |
Not an issue |
Not an issue |
Not an issue |
*1 |
*2 |
SUID Scripts or Programs
The first method is to create SUID scripts
or programs. This simply means that the file (the script or program) has the
Set-User ID permission set. The best example is the passwd
program. Users do not have write access to the /etc/passwd
file, yet when they change their password, the new password needs to be written
to the password file. As you can see from the file listing for the passwd command, it has an “s” in the execute column for the
owner.
-r-sr-xr-x 5 root bin
45056 Sep 23 00:00 /bin/passwd
This “s” gives the passwd program special permissions. When the passwd program is executed, it is executed as the owner of the program. Since the owner of the program is root, the program is executed as root and has write access to the password file. This is what allows users to change their passwords.
It would be easy for a system administrator to write a script to do the required tasks and turn the SUID bit on with the file owned as root. Yes, this would accomplish the task requirements. However, by doing this, you have given root access to this user. Since you wrote a SUID script, it can be assumed that you did not want the user executing the script to have root access. In the HP Press “HP-UX 11i Security” book and on various web-sites, the detailed steps are shown on how any regular user with execute access to a SUID script can gain root access. In summary, SUID scripts are a bad idea. SUID programs are safer, but also have their own risks. I would recommend using one of the other methods for distributing root privilege, however, if you are determined to do this, please check out: http://www.whitefang.com/sup/secure-faq.html and implement their suggestions.
sudo
The second method is an oldie but a goodie and the most implemented method among the bunch. The program sudo (superuser do) can be obtained from the HP-UX Porting and Archive Centre or from its home site at: http://www.courtesan.com/sudo/ . Once the application is installed the sudoers file needs to be configured. This file is a list of who can do what on which system(s). When editing this file you must use the visudo command that comes with the application. The following is a simple configuration file.
# Host alias
specification
Host_Alias PROD=hostone,hosttwo
Host_Alias DEV=hostfour
# User alias
specification
# Cmd alias specification
Cmnd_Alias MOUNT=/sbin/mount./sbin/umount
Cmnd_Alias SHUTDOWN=/sbin/shutdown
# User
privilege specification
#root ALL=(ALL) ALL
jrice PROD=MOUNT
jrice ALL=SHUTDOWN
smokey DEV=MOUNT
In this example two host alias groups are created. One for production (PROD) with two hosts (hostone and hosttwo) and the other for development (DEV) with one host (hostfour). In this example no user aliases are created. Next, command aliases are created. In this example two are created. The first called MOUNT that contains the mount and umount command. The second command alias is called SHUTDOWN and contains the shutdown command. In this example the alias names reflect the name of the command, but any alias name can be used.
The last step is to create the matrix of which user(s) can execute specific commands on specific hosts. In this example, the user jrice can execute the mount and umount command on hostone and hosttwo. This user can also execute the shutdown command on all three hosts (since the keyword “ALL” was used). This user cannot execute the mount and umount command on hostfour as this was not listed in the matrix. Users do not have to be listed individually, if a user alias had been created, that could be used to represent a group of users.
The following demonstrates how the user runs the sudo application:
$ whoami
jrice
$ /sbin/mount /dev/dsk/cdrom /cdrom
mount: must be root to use mount
$
$ /opt/sudo/bin/sudo /sbin/mount /dev/dsk/cdrom /cdrom
$ bdf | grep
cdrom
/dev/dsk cdrom 2457600 2457600 0 100%
/cdrom
In this example the regular user (jrice) needs to use the mount command. As the system administrator you have decided that you will allow this specific user to execute this command by making the appropriate configurations in the sudoers file. As shown above, this regular user cannot successfully run the mount command. The user is given the message “must be root to use mount”. However, when the user runs the sudo application and specifies the mount command, they are successful.
The sudo application logs activity. The following is a sample of a log entry for the successful use of the mount command:
Apr
25
COMMAND=/sbin/umount /cdrom
A log entry is also created when a user tries to use the sudo application to execute a command for which they do not have authorization. In this example the user was trying to change the password for the root user.
Apr
25
While sudo is a good method, it is not fool proof. Keep in mind that there is no easy way to prevent a user from creating a root shell if they have access to commands that are scripts or that allow shell escapes. Be cautious about what you set up in the sudoers file.
The sudo application has several advantages, particularly for those in a multi-vendor environment. The application is available for all UNIX platforms and the price is right (free!). However, if you are running a HP-UX only environment, I would recommend exploring the next two methods (Restricted SAM and SCM). If you are running HP-UX and Linux on HP servers, I would recommend using ServiceControl Manager. Both these methods are also available at no cost and have the added benefit of being supported by HP.
Restricted SAM
My tag line for Restricted SAM is: “WAIT A MINUTE! I know that just hearing the word SAM may give you the urge to purge”, but it really is a great solution for distributing root privileges. Some administrators might not like SAM, but you’re not going to use it. The user will be using this easy to use and intuitive tool, not you.
The System Administration Manager is a tool provided by HP for managing HP-UX systems. SAM is divided into the following sections:
User and Group Management
Auditing and Security
Backup and Recovery
Cluster Management
Disks and File Systems
Display
Kernel Configuration
Networking and Communications
Performance Monitors
Peripheral Devices
Printers and Plotters
Process Management
Routine Tasks
Software Management
Time
A subset of most of these areas can be assigned to any non-root user. Custom areas can also be created and assigned to users. YO! Did you hear that? Custom areas… that means you can put your own customized stuff in Restricted SAM. So, if something you need a non-root user to do as root isn’t in SAM, you can add it!
Before creating your own SAM tasks, create a custom group for storage of the tasks. This is done by logging on to SAM as root and selecting “Add Custom Application Group” from the Action menu. Fill in the name for the label. This will become the name of the new SAM area or group.
Next, create the customized task. In this scenario we will create a task to let the user mount the CD. The interface for creating a custom application can be found in the Action Menu. Move to the custom SAM area before adding the custom application. The custom application will reside in the SAM area where it was created. Select “Add a Custom Application” in the custom SAM area called Operations. Create a label to describe the task that is being created. When entering the command, be sure to include the full PATH with the command. The next field, “Execute Using”, has 3 options:
Root’s ID
User’s ID
Specific User
ID
Root’s ID would be selected when the task requires root capability. The User’s ID could be specified when the task needs to be executed as the user who is running SAM. The third option, Specific User ID, can be used for an application that needs to run as a specific user. This could be used for Oracle (oradba) or any other database or application.
Creating customized tasks is not a requirement for using Restricted SAM. If the tasks you need to delegate are in SAM by default, you do not need to create customized areas and tasks.
There are several nice features in Restricted SAM. The first being that the user is displayed only the SAM areas and tasks for which they are authorized. Another nice feature is that SAM can be used either with the Character User Interface or with the SAM GUI. The activity in Restricted SAM is logged to the samlog file (/var/sam/log/samlog). The following example is the audit activity generated by a user named jrice (UID=4004) using Restricted SAM to add a new user named sgruver.
@!@1@958083415@4004
Adding user sgruver
The system administrator configures Restricted SAM by running “sam –r” as the root user. This starts the Restricted SAM Builder. It is possible to configure Restricted SAM by editing files, but I don’t recommend it and it is not supported.
The first screen of the Builder is labeled “Load Privileges” and divided into two sections. The top portion contains a user list and the bottom section contains templates. If Restricted SAM has never been configured on your system, only one template, named default, will be displayed. Under the column “Has SAM Privileges” the word “No” will be displayed for all users. Go to the top field labeled “Load Privileges for Specific” and make sure it is “Users”. Next, go to the box listing all the users and select the user to receive Restricted SAM capabilities. On the lower half of the screen you must select a template type. Select default. After pressing “OK” a menu with all the SAM areas will be displayed. The Restricted SAM Builder screen contains all the SAM areas and access status to each area, including the customized areas you created. Access statuses include:
Disabled (all tasks under this area are disabled)
Enabled (all tasks under this area are enabled)
Partial (one or more tasks under this area are enabled)
Inaccessible (not used with Restricted SAM)
Turn all capabilities to disabled by selecting the Action Menu and “Disable All”. Now start enabling capabilities for each specific user. When you are finished configuring Restricted SAM be sure to save the changes. Take note of the field in the upper right hand corner labeled “Changes Pending”. If it displays “YES” the changes have not been saved. If you exit without saving your changes, they will be lost. The item “Save Privileges” can be found under the Action menu.
Once Restricted SAM has been configured, try running sam as this user to test the environment. This is done by issuing the following command:
sam –f “login name”
Only the authorized areas will be displayed. The last step prior to letting users loose is to make SAM available to them. By default, /usr/sbin, is not in the user’s PATH. The /usr/sbin directory can be added to the beginning of the user’s PATH, the user can be instructed to use the full pathname (/usr/sbin/sam), or you can create an alias for sam.
Restricted SAM also makes an easy to configure and simple to use menuing system for users.
The next article will cover the other two solutions: ServiceControl Manager and OpenView Operations.
Chris Wong is a technical consultant and trainer. She is
the author of the HP Press book HP-UX 11i Security. http://newfdawg.com
|
All Rights
Reserved, Copyright 2000 - 2002, TechTarget |
|
|
|
SearchHP.com
is a search service provided by TechTarget and is
completely |
||