Distributing root Privileges: Part 2of 2: ServiceControl ManagerBy Chris Wong
ServiceControl
Manager
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:
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
User Name
: root
Start
Time :
End
Time :
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.
OpenView Operations
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 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 |
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.
Summary
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. 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 |
||