Sample Sudo Policy for use with the pdossudo command
-----------------------------------------------------
The sample Sudo policy is an example of how to set up Sudo policy 
to give non-privileged users, who belong to the appropriate 
Tivoli Access Manager group based on the access controls put in place,
the ability to run the specified system administrative commands 
without needing to know the root password.  This sample policy is 
meant to demonstrate what is possible using Sudo policy.  It should 
be customized to meet the requirements of the current deployment.

Defining sample Sudo policy
---------------------------

The following files can be used to define Sudo authorization policy:

sample.sudo.policy.once
	Updates the Tivoli Access Manager User registry by:
	* creating the groups senioradmins, admins, and 
		operators (these groups do not have to map to local UNIX groups)
	* creating the users topgun, msadmin, mradmin, mroper, msoper
		(Note: these users should exist on the local machine as native UNIX users)
	* adding the users, mroper and msoper, to the operators group
	* adding the users, msadmin and mradmin, to the admins group
	* adding the user, topgun, to the senioradmins group
	* creating and modifying acls and pops for use during pdossudo testing, using
		the sample Sudo policy, see the file for details

sample.sudo.policy.<platform>.per-branch 
	Updates the Tivoli Access Manager Policy database by creating protected objects 
	and attaching access controls.  The file contains pdadmin commands 
	that can be used to define Sudo policy for TAMOS. This policy is 
        an example of how to set up Sudo policy to give non-privileged users 
        who belong to the appropriate Tivoli Access Manager group the ability to run 
	the specified operating system administrative commands without needing to
	know the root password.  Because privileged commands vary across operating 
	system platforms, two sample files are provided:

	* for Solaris: sample.sudo.policy.solaris.per-branch
	* for AIX: sample.sudo.policy.aix.per-branch


These two files can be used as input to pdadmin.  

The sample.sudo.policy.once file only needs to be used once for a given Tivoli Access Manager Policy 
database and can be used with both Solaris and AIX.

The sample.sudo.policy.<platform>.per-branch file is used for each distinct policy-branch 
where the policy is to be defined.  These files are platform specific because they
contain Sudo policy for platform specific privileged commands.
Use the sample.sudo.policy.solaris.per-branch file to define Sudo policy that can be
tested on a TAMOS Agent endpoint running on a Solaris system.  
Use the sample.sudo.policy.aix.per-branch file to define Sudo policy that can be 
tested on a TAMOS Agent endpoint running on an AIX system.  

Prerequisite steps on the target test system: 
1) Install and configure the TAMOS Agent.

2) Start the TAMOS Agent using the "rc.osseal start" utility, check the logs 
in /var/pdos/log for errors.

3) Create the local native users used by the Sudo policy, in the sample policy,
these users are topgun, msadmin, mradmin, msoper, and mroper.  The numeric uid doesn't 
matter, only the user name is important.  
Note: If the sample policy has been modified to use existing native users, this step
can be skipped.

4) If not using an existing policy branch in which to define the Sudo policy, create
the policy branch objectspace and the Sudo resource name (if using an existing policy branch,
this step can be skipped):
pdadmin -a sec_master -p <passwd> objectspace create /OSSEAL/<policy_branch_name> <description> 3
pdadmin -a sec_master -p <passwd> object create /OSSEAL/<policy_branch_name>/Sudo "Sudo resource" 3 i yes

5) Define the sample policy to the Tivoli Access Manager Policy database using the pdadmin command by
running the following commands as root:

# sed s/%SUFFIX%/<ldap_suffix>/g sample.sudo.policy.once | pdadmin -a sec_master -p <passwd>
For Solaris:
# sed s/%POLICY%/<policy_branch_name>/g sample.sudo.policy.solaris.per-branch | pdadmin -a sec_master -p <passwd>
For AIX:
# sed s/%POLICY%/<policy_branch_name>/g sample.sudo.policy.aix.per-branch | pdadmin -a sec_master -p <passwd>

where 
 <ldap_suffix> should be the Tivoli Access Manager User registry suffix under which the Tivoli Access 
	Manager for Operating Systems users and groups will be created during configuration,
	this is the value specified with the pdoscfg -suffix parameter

 <policy_branch_name> should be the name of a TAMOS policy branch the target system is configured to use

 <passwd> is the Tivoli Access Manager sec_master password


Executing pdossudo to exercise the Sudo policy
-----------------------------------------------

The following is a brief explanation of some testing that will exercise 
the sample Sudo policy on Solaris.  The Sudo policy defined for AIX 
can be exercised in a similar way using the defined policy.  Study the 
sample policy files to get ideas for testing that can be done on AIX 
or additional testing that can be done on Solaris.

General approach to validate and exercise the Sudo policy:

Login to the target system as one of the users defined in the policy.
For a given privileged command used in the Sudo policy that the user should be able to execute using pdossudo:
* verify that the user gets a permission denied type error if the user attempts to execute the binary directly
* verify that the user is allowed to execute the same privileged command if the user uses the pdossudo command

For a given privileged command used in the Sudo policy that the user should not be able to execute using pdossudo:
* verify that the user gets a permission denied type error if the user attempts to execute the binary directly
* verify that the user gets a permission denied type error if the user uses the pdossudo command

Examples of exercising some of the Sudo policy using specific privileged commands:

Actions performed by operators
-------------------------------

1) login as a user who is a member of the Tivoli Access Manager group, operators (for example, msoper)
	$ id
	uid=5391(msoper) gid=14(sysadmin)

2) Based on the sample Sudo policy, users who are defined in the Tivoli Access Manager group, operators, are able, when using pdossudo, 
to do privileged activities such as managing services using the svcadm command, without needing to know the root password.  
This can be demonstrated with the following commands:
  - Check state of the ftp service:
	$ svcs -l /network/ftp
	fmri         svc:/network/ftp:default
	name         FTP server
	enabled      true
	state        online
	next_state   none
	state_time   Thu Mar 27 14:53:22 2008
	restarter    svc:/network/inetd:default

  - Attempting to disable this service using the svcadm command directly fails:
	$ /usr/sbin/svcadm disable /network/ftp
	svcadm: svc:/network/ftp:default: Permission denied.

  - Disabling this service using pdossudo to run the svcadm command is successful:
	$ pdossudo svcadm disable /network/ftp

  - Check state of the ftp service to verify it is now disabled
	Verify service is disabled:
	$ svcs -l /network/ftp
	fmri         svc:/network/ftp:default
	name         FTP server
	enabled      false
	state        disabled
	next_state   none
	state_time   Fri Mar 28 09:16:53 2008
	restarter    svc:/network/inetd:default

  - Re-enable the service:
	$ pdossudo svcadm enable /network/ftp

3) Based on the sample Sudo policy, operators should not be able to do user administration regardless of whether the operator 
runs the operating system's user* command or tries to run one using pdossudo:
  - Attempting to add a new user using /usr/sbin/useradd directly fails:
	$ /usr/sbin/useradd -g staff -m -s /usr/bin/bash newuser
	UX: /usr/sbin/useradd: ERROR: Permission denied.

  - Attempting to add a new user using pdossudo to run /usr/sbin/useradd also fails:
	$ pdossudo useradd -g staff -m -s /usr/bin/bash newuser
	AOSUT0903E   The user is not authorized to execute the Sudo command alias.

4) Check that  TAMOS audit records were generated for the Sudo policy authorization decisions, 
this is because of the pop, sudo-enable-audit, which is attached at /OSSEAL/<branch_name>/Sudo.  
As the root user (or any user who is defined as a TAMOS auditor), run the following command:
# pdosaudview -z Sudo -n msoper -l 

Actions performed by admins
-------------------------------

1) login as a user who is a member of the Tivoli Access Manager group, admins (for example, msadmin)
	$ id
	uid=5388(msadmin) gid=14(sysadmin)

2) Based on the sample Sudo policy, users who are defined in the Tivoli Access Manager group, admins, are able, when using pdossudo, 
to do privileged activities such as user administration, without needing to know the root password.  
This can be demonstrated with the following commands:
  - Check that the user, newuser, does not exist in the /etc/passwd file:
	$ grep newuser /etc/passwd

  - Attempting to add a new user using the useradd command directly fails:
	$ /usr/sbin/useradd -g staff -m -s /usr/bin/bash newuser
	UX: /usr/sbin/useradd: ERROR: Permission denied.

  - Adding a new user using pdossudo to run /usr/sbin/useradd is successful:
	$ pdossudo useradd -g staff -m -s /usr/bin/bash newuser
	64 blocks

  - Grep newuser in /etc/passwd to verify the user was added
	$ grep newuser /etc/passwd
	newuser:x:5392:10::/export/home/newuser:/usr/bin/bash

On Solaris, the user account is locked until the passwd command is run.  For an administrator to effectively add a new user, the administrator
must also be able to set the user's password.  Let's assume that local policy dictates that when an administrator changes a user passwd, the user
must be required to change the password at the next login.  To achieve this, a sample shell script has been provided called set_passwd.sh which
changes the specified user's password and sets the password so it has to be changed at the next login.  Administrators are allowed to run this
script using the pdossudo command. 

    - Attempting to change the user's password using the passwd command directly, fails:
	$ passwd newuser
	Permission denied
 
    - Changing the new user's password using the pdossudo command to run the set_passwd.sh script is successful:
	$ pdossudo set_passwd newuser
	New Password:
	Re-enter new Password:
	passwd: password successfully changed for newuser
	passwd: password information changed for newuser

3) Based on the sample Sudo policy, admins should not be able to su to the root user without knowing the root password, regardless of whether or not
the administrator runs the operating system's su command directly or tries to run it using pdossudo:
  - Attempting to su to root fails if the root password is not provided:
	$ su
	Password:
	su: Sorry

  - Attempting to use pdossudo to su to root fails:
	$ pdossudo su
	AOSUT0903E   The user is not authorized to execute the Sudo command alias.

4) Check that  TAMOS audit records were generated for the Sudo policy authorization decisions, 
this is because of the pop, sudo-enable-audit, which is attached at /OSSEAL/<branch_name>/Sudo.  
As the root user (or any user who is defined as a TAMOS auditor), run the following command:
# pdosaudview -z Sudo -n msadmin -l 

Actions performed by senioradmins
---------------------------------

1) login as a user who is a member of the Tivoli Access Manager group, senioradmins (for example, topgun)
	$ id
	uid=5386(topgun) gid=14(sysadmin)

2) Based on the sample Sudo policy, senioradmins should not be able to su to the root user without knowing the root password if attempting to use the
/usr/bin/su command directly; but senioradmins can su to root when using the pdossudo command to run su:
  - Attempting to su to root fails if the root password is not provided:
	$ su
	Password:
	su: Sorry

  - Using pdossudo to su to root is successful:
	$ pdossudo su
	Enter your password:
	IBM's internal systems must only be used for conducting IBM's business
	or for  purposes authorized by IBM management.
	Use is subject to audit at any time by IBM management.
	
	You have new mail.
	# id
	uid=0(root) gid=0(root)


4) Check that TAMOS audit records were generated for the Sudo policy authorization decisions, 
this is because of the pop, sudo-enable-audit, which is attached at /OSSEAL/<branch_name>/Sudo.  
As the root user (or any user who is defined as a TAMOS auditor), run the following command:
# pdosaudview -z Sudo -n topgun -l 

Removing the sample Sudo policy
--------------------------------
The following files can be used to remove sample Sudo authorization policy if you 
no longer want it defined:

sample.sudo.policy.<platform>.per-branch.cleanup
	Updates the Tivoli Access Manager Policy database by deleting protected objects 
	and detaching access controls.  These file contains pdadmin commands 
	that can be used to remove Sudo policy for TAMOS:
	* for the Solaris policy: sample.sudo.policy.solaris.per-branch.cleanup
	* for the AIX policy: sample.sudo.policy.aix.per-branch.cleanup

sample.sudo.policy.once.cleanup
	Updates the Tivoli Access Manager User registry by:
	* deleting acls and pops for use during pdossudo testing, using the sample Sudo policy, see the file for details
	* removing the users, mroper and msoper, from the operators group
	* removing the users, msadmin and mradmin, from the admins group
	* removing the user, topgun, from the senioradmins group
	* deleting the users topgun, msadmin, mradmin, mroper, msoper 
		(Note: these users should be manually deleted from the local machine if no longer needed)
	* deleting the groups senioradmins, admins, and operators 

Note: if you modified the sample policy files before defining the Sudo sample policy, then you should modify
the cleanup policy files accordingly or manually remove the policy using the pdadmin command directly.

1)Remove the sample per-branch policy from the Tivoli Access Manager Policy database using the pdadmin command by
running the following commands:

For the Solaris defined policy:
# sed s/%POLICY%/<policy_branch_name>/g sample.sudo.policy.solaris.per-branch.cleanup | pdadmin -a sec_master -p <passwd>

For the AIX defined policy:
# sed s/%POLICY%/<policy_branch_name>/g sample.sudo.policy.aix.per-branch.cleanup | pdadmin -a sec_master -p <passwd>

Remove the sample policy that was defined using the sample.sudo.policy.once file from the Tivoli Access Manager Policy database 
using the pdadmin command by running the following commands:
NOTE: Only run this command if you are sure there is no policy defined using the Sudo sample policy acls, test users, and test groups

# sed s/%SUFFIX%/<ldap_suffix>/g sample.sudo.policy.once.cleanup | pdadmin -a sec_master -p <passwd>

where 
  <ldap_suffix> should be the Tivoli Access Manager User registry suffix under which the TAMOS 
  users and groups will be created during configuration, this is the value specified with the pdoscfg -suffix parameter

 <policy_branch_name> should be the name of a TAMOS policy branch the target system is configured to use

 <passwd> is the Tivoli Access Manager sec_master password

2) If you did not use an existing policy branch for testing the sample Sudo policy, you can delete
the policy branch objectspace and the Sudo resource name (if you used an existing policy branch,
this step can be skipped):
pdadmin -a sec_master -p <passwd> object delete /OSSEAL/<policy_branch_name>/Sudo
pdadmin -a sec_master -p <passwd> objectspace delete /OSSEAL/<policy_branch_name>

