Users submit their requests to run certain programs as root, or another privileged account, through Privilege Manager for Unix 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 run 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 for Unix accepts the request, the Privilege Manager for Unix 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. For more details, see PM settings variables.
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. For more details, see Privilege Manager for Unix shells.
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; }
Do not use a leading zero for any time between 00:00 and 9:59 a.m. For example, when specifying 7:00 a.m., use 700 rather than 0700. Specify 12:30 am as 30 or 2430. Privilege Manager for Unix interprets numbers with leading zeroes as octal numbers: 0700 octal is 560 decimal, which is not a valid time.
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.
For more information about the syntax and usage of this command, see pmpolicy.
Before you run the installer, consider the following questions:
-
Which machines in your network will run policy servers?
If you only plan to use one policy server for an entire network, it should be the most reliable and secure machine.
You can specify multiple policy servers to avoid having a single point of failure.
If more than 150 users will be using a single pmmasterd for validation, you will want to have multiple policy servers to avoid a UNIX network resource bottleneck. Plan to have a maximum of 150 users validating at a single policy server.
-
Which machines will be managed hosts?
Only those hosts running the local daemon (PM Agent package) may receive and run Privilege Manager for Unix requests. For more details, see pmlocald.
One Identity recommends that you initially specify one policy server and three or four local hosts when you first install and experiment with Privilege Manager for Unix.
-
What level of protection do you require?
If you require greater protection, you can select an encryption level such as AES, or a dedicated encryption system such as Kerberos. When configuring Privilege Manager for Unix in interactive mode, you are asked if you are using Kerberos. If you are using Kerberos, Privilege Manager for Unix automatically uses Kerberos for encryption.
You can configure the policy file to require a checksum match to authorize program execution. If configured in the policy, Privilege Manager for Unix runs the program only if its checksum matches that configured in the policy file. By default, it uses a CRC algorithm, but you can configure the MD5 algorithm instead by setting the keyword checksumtype to MD5 in pm.settings.
-
Which port numbers should pmmasterd and pmlocald use to listen for network requests?
Choose numbers that do not conflict with other numbers in the /etc/services file. Ensure these entries are propagated to all machines accessing Privilege Manager for Unix.
-
Which directory should contain the Privilege Manager for Unix log files?
By default, the log files are placed in /var/adm or /var/log depending on the host architecture. The installer allows you to change the directory by specifying command line options to the Privilege Manager for Unix daemons. The partition needs to contain enough space for log files to increase in size.
Prior to installing Privilege Manager for Unix, ensure your system meets the minimum hardware and software requirements for your platform.
Table 1: Hardware and software requirements
|
Operating systems |
See Supported platforms to review a list of platforms that support Privilege Manager for Unix clients. |
|
Disk space |
80 MB of disk space for program binaries and manuals for each architecture.
Considerations:
-
At a minimum, you must have 80 MB of free disk space. The directories in which the binaries are installed must have sufficient disk space available on a local disk drive rather than a network drive. Before you install Privilege Manager for Unix, ensure that the partitions that will contain /opt/quest have sufficient space available.
-
Sufficient space for the keystroke logs, application logs, and event logs. The size of this space depends on the number of servers, the number of commands, and the number of policies configured.
-
The space can be on a network disk drive rather than a local drive.
-
The server hosting Privilege Manager for Unix must be a separate machine dedicated to running the pmmasterd daemon. |
|
SSH software |
You must install and configure SSH client and server software on all policy server hosts.
You must enable access to SSH as the root user on the policy server hosts during configuration of the policy servers. Both OpenSSH 4.3 (and later) and Tectia SSH 6.4 (and later) are supported. |
|
Processor |
Policy Servers: 4 cores |
|
RAM |
Policy Servers: 8 GB |
