Set Lesson number variable
Lessons 1-10 are controlled by an environment variable called LESSON. Set this to a number in the range 1 through 6, using the following command:
LESSON=1; export LESSON
The main policy file, pm.conf, reads the LESSON and LESSON_USER environment variables and assigns their values to the PMLESSON and PMLESSON_USER policy variables, respectively.
The following example instructs you to run a fictitious command, fred, under Lesson 1.
You use the pmrun command to submit commands to Privilege Manager for Unix. Try entering fred using pmrun.
To enter a fictitious command
-
At the command line, run:
# su demo
$ pmrun fred
Lesson 1 is selected
-------------LESSON 1 DESCRIPTION---------------------------
Policy file /opt/quest/pm4u/examples/linux-intel/example1.conf
------------------------------------------------------------
This basic lesson uses a policy allowing users dan and demo
the rights to run any command as root.
For example, to test this, enter the command pmrun whoami
which will return the value root as the logged in user.
-----------------------------------------------------------
fred
3201.063 Exec of fred failed: Command not found
As you can see, the policy informs you which lesson is selected and also provides the path to the associated policy file which contains this lesson fragment.
The policy files are reproduced in Sample policy files for your reference, but you are encouraged to look at the digital copies of these files and experiment with the constructs that they contain once you have completed the lessons.
Introductory lessons
The first seven lesson introduce you to some of the simpler constructs and capabilities of Privilege Manager for Unix's policies. Each lesson builds upon the precepts of the last lesson. By the end of the seventh lesson you will have sufficient knowledge to start building your own policies.
These are the introductory lessons:
Lesson 1: Basic policy
This lesson introduces the basic concept of running a command at a privileged level. For a given list of users (in this case, dan and your defined LESSON_USER), run the command as root.
Here is the relevant policy code:
if (user=="dan" || user==PMLESSON_USER) {
runuser="root";
accept;
}
If the policy server evaluates the policy without reaching an explicit "accept" statement, the request is rejected.
Be sure to:
-
Set the LESSON variable to 1.
-
Switch to your test user.
-
Enter the command pmrun whoami.
Text in bold represents commands you enter; the resulting output is shown in normal font. The command output for the pmrun commands below has been slightly modified for brevity.
# LESSON_USER=demo; export LESSON_USER
# LESSON=1; export LESSON
# su demo
$ whoami
demo
$ pmrun whoami
root
$ exit
As you can see the result of the whoami command without a pmrun prefix shows that you are logged in as user demo. Repeating the command with a pmrun prefix, shows that you ran the command as root.
Here is the policy code that implements this behavior:
if (user=="dan" || user==PMLESSON_USER) {
runuser="root";
accept;
}
If the user who submitted the pmrun request matches either "dan" or the PMLESSON_USER variable, the runuser is set to "root" and the request is accepted.
The exit command at the end returns you to the root shell before proceeding to the next lesson.
To see the sample policy used in this lesson, see Lesson 1 Sample: Basic policy.
Lesson 2: Conditional privilege
This lesson builds upon the previous lesson by narrowing the conditions under which you can run the commands as root. It introduces the use of a policy variable, dayname, and the function, timebetween(), to ensure that you can only run commands within the predetermined time frame of typical office hours (weekdays, between 8:00 a.m. and 5:00 p.m.).
The dayname variable and the timebetween() policy function are used to reject requests outside office hours:
if(dayname=="Sat" || dayname=="Sun" || !timebetween(800,1700))
reject;
This lesson assumes that the current date and time are within this time frame.
# LESSON=2; export LESSON
# su demo
Now, change the system date and attempt the command again using the following commands:
$ pmrun date mmdd2100
Thu Feb 26 21:00:00 EDT 2012
$ pmrun date mmdd2100
Request Rejected by pmmasterd on UPMhost
$ exit
where:
-
mm stands for month (for example, 03 for March)
-
dd stands for day (for example, 10 for the 10th)
The output shown above illustrates that the first attempt to set the date succeeded because the system date was within normal office hours. The second attempt fails because the time is now set outside of normal office hours.
Remember to reset the correct time on your system by running the date command as the root user.
To see the sample policy used in this lesson, see Lesson 2 Sample: Conditional privilege.
