ServiceControl Manager (SCM) is described as "a single point of administration for multiple HP-UX systems that provides up to five times more productivity for system administrators". SCM was designed as a tool for centralized management of multiple HP-UX and Linux systems. However, it can also be used on a stand-alone server and is an excellent tool for distributing root (and other) privileges.
As mentioned in Part 1 of this series, one of the administrational challenges of UNIX is its lack of role-based users. In SCM functionality is wrapped around commands, scripts, file-copy, and applications in order to allow role-based security policies for system administration and configuration. The following HP-UX products are integrated into SCM: EMS (Event Monitoring System), SAM, Ignite/UX and Recovery, Online JFS, Software Distributor/UX, the System Configuration Repository (SCR), and the Security Patch Check Tool. A set of HP-UX commands is also integrated with SCM. Customized tools can be added as well, making SCM a complete, centralized management solution for the HP-UX and Linux environment. But don't forget that it is also a complete tool for distributing privileges in a single system environment.
Three interfaces are available with SCM: GUI, Web, and command line. Since it also includes command line, this will make it attractive to a larger audience of users. The command line is available for the junior administrators, programmers, and DBAs. The GUI and Web interface are available for other users.
To use SCM a quick understanding of roles and tools is necessary. A role is simply a collection of users. For example, a role can be created called DBA. A list of users (this being their HP-UX login name) is added to this role. A user can belong to multiple roles. A tool is simply a task that you assign to a role. As listed above, many tools are automatically integrated with SCM. If a tool is needed that is not already integrated, a customized tool can be created. Once the tool is added, any user who is a member of the role(s) assigned to the tool will be able to execute the command on any node(s) on which they are authorized to run commands.
In the following example, a tool was created to allow the user to edit the nsswitch file. This customized tool requires a window. If using the web-interface or GUI, the user could select the "nsswitch" icon to configure the /etc/nsswitch.conf file or they could run the tool from the command line as shown below:
ctg500: whoami joeuser ctg500: export DISPLAY=192.168.1.104:0.0 ctg500: mxexec -t nsswitch -n ctg700 Running tool nsswitch with task id 16 Task ID : 16 Tool Name : nsswitch Task State : Complete User Name : root Start Time : Sunday, February 3, 2002 10:07:42 PM PST End Time : Sunday, February 3, 2002 10:07:42 PM PST Elapsed Time : 176 milliseconds Node : ctg700 Status : Complete Exit Code : 0 STDOUT : <No output>
In the above example, the user is running the tool (-t) named nsswitch to be run on node (-n) ctg700. You may note that the user is currently only logged on ctg500. The "User Name" field indicates the user that the tool will be executed as on the node. In this example it is "root" since only "root" has access to edit this file. Following the above output, the screen is displayed that allows the user to edit the nsswitch.conf file.
SCM is a product with a large amount of functionality. In my book, I dedicate a chapter to this product. HP Education covers SCM in h7102s - Multi-System Management. (Remember, you do not need multiple systems to run SCM). One thing that I have implemented is using the "startup" and "shutdown" scripting structure with SCM. This is one way of limiting what arguments can be passed to a tool. This also gives additional flexibility in a multi-system environment if you also implement the "on" or "off" flag in the configuration file. Using this, a user in SCM may be authorized to run a tool on a given node, but instead of changing their SCM authorizations, you can simply change the flag in the configuration file for a given node.
Another important feature of SCM is that it can automatically distribute any changes that you make to scripts or programs to other systems. As mentioned in the beginning of the description of SCM, file-copy is an included feature. If you have a program or script that is part of a tool, you can create the tool to automatically copy the latest version to the node. This eliminates the problem of implementations.
SCM adds role-based policies to both HP-UX and Linux (running on HP supported platforms), is scaleable, and has three interfaces. It also will require more system resources than the other solutions mentioned in part 1 of this series.
The last method for distributing privileges is the Operations product from the OpenView family. The Operations product would be best suited if you have a multi-vendor multi-host environment and/or require integration with other OpenView products or third party plug-ins. Operations is a powerful tool and requires dedicated time for training and implementation. As shown in the following table, there is no command-line interface for users.
|Tools ->||SUID Scripts
|sudo||Restricted SAM||SCM||OpenView Operations|
|Supported by HP||No||No||Yes||Yes||Yes|
|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|
|System Resources||Not an issue||Not an issue||Not an issue||*1||*2|
*1: May require additional memory on ServiceControl Manager's Central Management Console.
*2: Dedicated Operations Host (HP-UX, Sun, or Windows) recommended.
If you are looking for a tool that will automatically respond to specific events, Operations is for you. If you are looking to implement role-based functionality (distributing privileges) only, this does not justify the cost of the product, unless you have the need to do this across multi-vendor platforms.
In summary, choosing the best solution for your site depends on the variables in your environment. A combination of two or more methods is usually the best solution. In any case, implementing any of these methods is better than giving root access to someone that should not have it.
Another consideration is the potential security risks associated with distributing a root (or other powerful user) privilege to a non-privileged user. For example, when using Restricted SAM for user management there are a few rules you should know about regarding the user who is doing the management:
Cannot add user with UID 0
Cannot change the password of a user with the UID of 0
Cannot remove a user with the UID of 0
Cannot deactivate a user with UID of 0
Can change the home directory of a user with UID 0
Can create a new home directory for a user with UID 0
Can change the login shell or startup program for a user with UID 0
The last three rules do pose a possible security risk. For each implementation it is important to review the potential risks associated with each tool. This not only includes the tool itself, but the mechanism used to implement the tool. For example, if the solution has a web-based GUI, what security is built into this? In the bigger picture, the security of these non-privileged users who temporarily gain privileged status must also be reviewed. Questions such as the mechanism they use to connect to the server (are they using telnet, telnet over IPSec, or SSH?) and the quality of their password (is it easily crackable, is aging enforced?) need to be addressed.
Chris Wong is a technical consultant and trainer for Cerius Technology Group in Bellevue, WA. She is the author of the HP Press book "HP-UX 11i Security".