A sudo type policy is used with the Safeguard for Sudo product. When you configure the primary policy server, if /etc/sudoers exists, it imports this file and uses it as the initial sudoers policy file. Otherwise, it creates a generic sudoers file.
By default, the Safeguard for Sudo sudoers file resides in /etc/opt/quest/qpm4u/policy/sudoers, but is not meant to be accessed directly.
Example: Sudo type policy rules
Sudo type policy rules look like as follows:
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
TIP: Sudo processes rules from top to bottom. This means that the order of rules is important because the last rule takes precedence. For this reason, always place exceptions under the generic settings.
Sudo rules are displayed in columns, denoting:
Different columns can be replaced with lists, and by using an alias, you can use a list in multiple places. The reserved word ALL is a built-in alias, that, when used in a command context, allows any user to run any command.
-
Lines starting with Defaults are generic rules that change the default behavior of sudo. The line starting with Defaults in this example is a rule that applies to all users (but it can be limited to a subset of users).
-
Lines starting with a user name (or a list of user names) are rules granting permissions to specific users. The line starting with root in this example is a rule granting permission to the root user to run any command on any host as any user.
-
Lines starting with a % mark and a group name are rules granting permissions to a specific group. The line starting with %wheel in this example is a rule granting permission to all users in the wheel group to run any command on any host as any user.
NOTE: You must prepend a percentage sign (%) in front of groups, but not in front of users.
In short, the example will let the root or any user in the wheel group run any command on any host as any user. However, even in this case, using sudo is beneficial because you can allow certain users to run commands as root without sharing the root password, while by logging all commands and arguments, sudo also provides an audit trail of the users doing so.
For more information on Defaults, aliases, or the sudoers syntax in general, see the Sudoers man page.
To view a summary of the changes you made to your security policy
-
At the command line, run:
# pmpolicy log
** Validate options [ OK ]
** Check out working copy [ OK ]
** Retrieve revision details [ OK ]
version="3",user="pmpolicy",date=2012-07-11,time=15:43:30,msg="add sudoers.d/helpdesk "
version="2",user="pmpolicy",date=2012-07-11,time=15:38:21,msg="add #includedir sudoers.d"
version="1",user="pmpolicy",date=2012-07-11,time=15:35:19,msg="First import"
-
To examine the differences between two versions, run:
# pmpolicy diff -r1:2
** Validate options [ OK ]
** Check out working copy (trunk revision) [ OK ]
** Check differences [ OK ]
** Report differences between selected revisions [ OK ]
- Differences were detected between the selected versions
Details:
Index: sudoers
===================================================================
--- sudoers (revision 1)
+++ sudoers (revision 2)
@@ -88,6 +88,6 @@
# Defaults targetpw # Ask for the password of the target user
# ALL ALL=(ALL) ALL # WARNING: only use this together with 'Defaults targetpw'
-## Read drop-in files from /etc/sudoers.d
+## Read drop-in files from sudoers.d
## (the '#' here does not indicate a comment)
-##includedir /etc/sudoers.d
+# includedir sudoers.d
The output shows the sudoers file from line 88. The lines that were changed between version 1 and version 2 are marked with a preceding “+” or "-". A "-" denotes lines that were changed or deleted, and a "+" denotes updated or added lines.
The pmgit utility is a tool that can mediate version control operations between Subversion (SVN) and Git version control systems.
The pmgit utility uses the internal SVN policy repository to apply policies to the system, but it also uses an intermediate Git-SVN repository to keep the local SVN policy repository up-to-date from an external Git policy repository. You can manage this Git repository from outside the primary policy server.
The pmgit utility uses the git and git svn tools to perform the required version control operations, so you must install these tools on the Privilege Manager for Unix primary policy server. You can install both git and git svn using the system-specific package manager.
pmgit policy management concept
When you enable Git policy management, pmgit creates a backup from the original SVN policy repository which you can later restore if needed.
You can configure the Git policy management interactively by running the pmgit --interactive command.
There are two major advantages of the Git policy management:
-
You can make changes in policies from anywhere, where the Git policy repository is available without the need to log into the policy server.
-
You can use the "Git-workflow" by separating development and production branches, creating pull requests, having reviews before merge, and so on.
In this mode, you can no longer edit policies on the policy servers (neither primary, nor secondary). The pmpolicy command will reject every request that would make changes in the local SVN policy repository.
Under the hood, Privilege Manager for Unix policy servers still use the original SVN policy repository when updating policies, but the pmgit utility synchronizes the changes from Git to SVN using a local Git clone of the remote Git policy repository. The local copy is created at the following location:
/var/opt/quest/qpm4u/.qpm4u/.repository
Do not edit the local Git clone because it is maintained by the pmgit utility. Any changes made to the local Git clone will be discarded when pmgit synchronizes the changes from the remote Git policy repository.
The Git-SVN synchronization can either be manual or periodic, based on a predefined interval.
Before applying changes to the SVN policy repository, pmgit checks for syntax errors in the updated policy files. If no errors are found, pmgit creates a new SVN commit with the changes on top of the trunk. If a syntax check fails, pmgit logs the error reason via syslog. Optionally, pmgit can run a user-defined script (alert script) to take custom actions.
To enable Git policy management with the default settings, use the following command:
pmgit enable --export --git-url https://github.com/user/example.git
In this example, the Git policy repository at the specified URL must exist and must be an empty bare repository, or Git will reject the operation.
You can optionally configure the following settings:
-
Git branch (Default: master)
-
Update interval (Default: 5 minutes)
-
Alert script (Default: N/A)
Each of the settings are stored in Privilege Manager's main configuration file (pm.settings).
For more information on pmgit subcommands, see pmgit.
Before using Git policy management, do the following:
-
Install the git tool on the primary policy server using the system-specific package manager.
-
Install the git svn tool on the primary policy server using the system-specific package manager.
-
Configure the git tool for passwordless authentication to allow automatic synchronization between the primary policy server and the remote Git repository.
-
Enable Git policy management mode in the pmgit tool.
