Safeguard for Sudo 2.0 - Administrators Guide

How Privilege Manager for Unix Works

The three main Privilege Manager for Unix components are:

• The Client: The client is effectively the user who runs a command from their local machine by simply performing commands as root using the pmrun prefix.
• The Policy Server: The policy server checks all commands with the policy file to ensure that the user is allowed to run the command, it then passes the command on to the agent for action. The policy server also logs the output result (that is, whether the command was successfully actioned or not), whether you enable keystroke logging or not.

  If you enable keystroke logging, it creates a much more detailed set of log files. The input/output log stores everything from keystrokes to input and output data. The event log purely records all of the requests made and their result.

• The Agent: The agent performs the commands which are issued from the policy server and passes the result back to the client.

Figure 2: Privilege Manager for Unix Components

Privilege Manager for Unix comprises four main programs:

• pmrun
• pmmasterd
• pmlocald
• pmtunneld

Users submit their requests to run certain programs through Privilege Manager for Unix using pmrun. For each request, the user may specify a program name and optionally a host on which the program will run.

The configuration file policy server master daemon (pmmasterd) examines each user request and either accepts or rejects it based upon information in the Privilege Manager for Unix configuration file. You can have multiple pmmasterd daemons on the network to avoid having a single point of failure.

Policy Configuration File (pmpolicy security policy)

Users submit their requests to run certain programs as root, or another privileged account, through Privilege Manager using pmrun. The policy server daemon, pmmasterd, examines each request from pmrun, and either accepts or rejects it based upon the policies specified in the policy file.

The Privilege Manager for Unix configuration file (also referred to as the pmpolicy security policy) contains the security policy that the policy server master daemon (pmmasterd) considers when it accepts or rejects user requests. The configuration file can specify constraints based on certain attributes, such as:

• Username
• Group membership
• Application name
• Application arguments
• Environment variable values
• Umask (file permissions)
• Nice value (priority of jobs run)
• Working directory from which the request may be made
• Host from which a request can be submitted (submitting host)
• tty from which a request is submitted
• Host from which the request will be run (execution host)
• A remote, dedicated host to store iologs and/or eventlogs
• Time of day and day of week that the user is allowed to run the application
• Exit status or output of any specified program to be executed as part of the decision-making process
• A challenge to the user to type in one or more specified user passwords (requires on-the-spot approval from those users, such as supervisors or managers)
• Whether the program being requested has a checksum that matches the one stored for that application in the configuration file (protects against possible virus or trojan horse attack)
• Store all information for each request in a log file
• Record all keystrokes and/or output in a dribble file
• Some other miscellaneous job properties

If Privilege Manager accepts the request, the Privilege Manager local daemon (pmlocald) runs the application program as the runuser selected in the policy file, piping all input/output back to the user’s terminal. In addition, you can specify in the configuration file that you want to store all information for each request in a log file, and optionally record all keystrokes, output, or both, in an I/O file for later replay. You can replay the file in real time, so you can observe the commands as they are issued.

You can restrict responses to a small designated range of reserved port numbers by setting parameters in /etc/opt/quest/qpm4u/pm.settings. This enhances the security of communications between pmlocald and pmmasterd when the two must communicate across a firewall. (See PM Settings Variables for details.)

Privilege Manager for Unix utilizes NAT (Network Address Translation) to further restrict responses to a single designated port when pmlocald and pmmasterd must communicate across a firewall.

You can issue commands either in the foreground or background. If you run them in the background, you can continue to use the same shell process to issue additional commands. (See Privilege Manager Shells for details.)

The policy file is:

• Located on the policy server daemon host
• Created in pm.conf

  By default, the policy file is named pm.conf and is located in the directory specified by policyfile. If the full path name for the pm.conf file is not specified in policyfile, the path is relative to policydir.

• Owned by root

Only root can have write permission for the configuration file. Otherwise, a user might gain illegal access to the root account through modification of the file. To prevent someone from replacing the entire /etc directory or its contents, both / and /etc have permission modes that do not allow users to modify them.

The configuration file contains statements and declarations in a language specifically designed to express policies concerning the use of root and other controlled accounts.

For example, if your policy is: Allow user robyn to run the /bin/passwd program as root on the galileo machine Monday through Friday, during office hours (8:00 a.m. to 5:00 p.m.), add the following to your policy file:

weekdays={"Mon", "Tue", "Wed", "Thu", "Fri"}; if (user=="robyn" && command=="passwd" && host=="galileo" && timebetween(800, 1700) && dayname in weekdays) { runuser="root"; runcommand="/bin/passwd"; accept; }

Policy Group

A policy group is a group of one or more policy servers – one primary server and any number of secondary servers. You can configure multiple policy servers in a policy group to share a common configuration for load balancing and redundancy.

Policy servers are responsible for evaluating the security policy and accepting or rejecting the agent request based on the constraints in the security policy. A policy group is one or more policy servers which have been configured to share a common policy.

Figure 3: Policy Group

When the first policy server in the group is configured, it becomes the primary policy server and sole member of the policy group. To support load balancing and redundancy, you may add secondary policy servers to the policy group.

If a policy server becomes unavailable for any reason, hosts joined to the group will find the next available server in the policy group to service their requests. Any failover is transparent to the hosts, as the same policy is enforced by all policy servers within the policy group.

The primary policy server hosts the master copy of the policy from which the secondary servers receive updates. You can initiate changes to the policy from any policy server using the pmpolicy command. Once completed, the changes are committed to the master copy, and policy servers are automatically updated.

What's New in Privilege Manager 6.0

One Identity Privilege Manager for Unix 6.0 includes the following major enhancements:

• Privilege Manager event activity is now logged in a database format; use the new pmlogadm command to administer the database files.
• One Identity Management Console for Unix now supports Privilege Manager for Unix.
• The profile-based policy has been improved, including a new naming convention for the variables that you use to construct the security policy file.
• The Privilege Manager for Unix documentation is now consolidated into a single Administrator Guide.