Chat now with support
Chat with Support

Safeguard for Sudo 7.3 - Administration Guide

Introducing Safeguard for Sudo Planning Deployment Installation and Configuration Upgrade Safeguard for Sudo System Administration Managing Security Policy Administering Log and Keystroke Files Supported sudo plugins Troubleshooting Safeguard for Sudo Variables Safeguard for Sudo programs Installation Packages Supported Sudoers directives Unsupported Sudo Options Safeguard for Sudo Policy Evaluation

Example setup with GitHub

To create a Private repository on GitHub

  1. Log in to Github with a valid account.

  2. Create a new Private repository with a name you want, for example, sas-example:

    You do not need to initialize the repository with a commit (readme/gitignore/license), but feel free to do so if you want.

  3. Check the URL of the repository. Use the repository link for SSH access:

  4. On the primary policy server host, generate a secure enough SSH key that GitHub accepts (it no longer accepts RSA keys):

    root@qpmserver:~> ssh-keygen -t ecdsa
    Generating public/private ecdsa key pair.
    Enter file in which to save the key (/root/.ssh/id_ecdsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /root/.ssh/id_ecdsa.
    Your public key has been saved in /root/.ssh/id_ecdsa.pub.
  5. Optional: This keypair either needs to be at the standard place, or you need to tell SSH or Git which one to use, for example, create a file under ~/.ssh/config:

    Host github.com
        IdentityFile ~/.ssh/id_ecdsa.github
        IdentitiesOnly yes
  6. Add rights for the owner of the key to access your repository. For this, go back to the browser at your repository on GitHub. Open Settings > Security > Deploy keys. Add your public key (/root/.ssh/id_ecdsa.pub). If you want to export your current SVN to this repository, Safeguard for Sudo will need write access, otherwise read only access is enough.

  7. Start pmgit in interactive mode and answer the questions. In this example, we have exported the current policies to our new git repository:

    Select an option
    1) Export the current SVN policy repository to a Git repository.
    2) Import an existing Git policy repository.
    
    Select an option [1-2] (1) 1
    
    > You will export your local SVN policy repository to an empty Git repository.
    
    Git URL is the URL path to your Git project (for example: https://github.com/user/example.git).
    Enter the Git URL (): git@github.com:manner82/s4s-example.git
    
    The name of the Git branch where you store your policies (for example, main).
    Enter the name of the branch (master): main
    
    Local SVN policy repository update interval.
    Enter the update interval in minutes [0-60] (5): 30
    
    You can specify a script that is called automatically if pmgit fails to synchronize your local SVN policy repository.
    This setting is optional, you can leave it empty.
    Enter the script path ():
    
    Are you sure these settings are correct? [Y/n] y

Administering Log and Keystroke Files

Safeguard for Sudo allows you to control what is logged, as well as when and where it is logged. To help you set up and use these log files, the topics in this section explore enabling and disabling logging, as well as how to specify the log file locations.

Safeguard for Sudo includes three different types of logging; the first two are helpful for audit purposes:

  • keystroke logging, also referred to as I/O logging

    Keystroke logs record the user’s keystrokes and the terminal output of any sessions granted by Safeguard for Sudo.

  • event logging

    Event logs record the details of all requests to run privileged commands. The details include what command was requested, who made the request, when the request was sent, what host the request was submitted from, and whether the request was accepted or rejected.

  • error logging

You can configure some aspects of the event and keystroke logging by means of the security policy on the policy servers. What you can configure and how you configure it depends on which type of security policy you are using on your policy server -- pmpolicy or sudo.

Related Topics

Security policy types

Configuring keystroke logging for Safeguard for Sudo policy

Safeguard for Sudo enables event logging. Each time a sudo command is run, the policy server accepts or rejects the requested command according to the sudoers policy file and creates an event (audit) log. If enabled, the policy server records the keystroke input and terminal output for each accepted command, creating comprehensive "keystroke logs" files. With these logs, you can perform forensic-level auditing of any command that ran by means of sudo.

Event logs are captured and stored on the policy servers in /var/opt/quest/qpm4u/pmevents.db; keystroke logs are stored at /var/opt/quest/qpm4u/iolog.

You can use the iolog_dir and iolog_file policy options to reconfigure the iolog file location.

Configure the sudoers policy for keystroke logging by using the log_input and log_output defaults flags, or the LOG_INPUT and LOG_OUTPUT command tags, as follows:

Defaults log_input, log_output # keystroke logging enabled 
Defaults!/sbin/reboot !log_input,!log_output # no logging for reboots 

For complete I/O log records you must use both log_input and log_output.

# disable keystroke logging for the pmreplay command 
ADMINS ALL = (ALL) NOLOG_INPUT:NOLOG_OUTPUT:/opt/quest/sbin/pmreplay 

ADMINS is a User_Alias. See the Sudoers man page for definition of User_Alias.

Validating Sudo commands

To validate that the centrally managed policy is working, log on to a policy server (or a Sudo Plugin host) as a non-root user, run a command that is already set up in your sudoers policy file and observe the results.

Use a command you expect to work, such as:

$ sudo id

Then run a command that you know you do not have sufficient privileges to run. For instance, run a fake command, such as:

$ sudo fakecmd

When Safeguard rejects a command, it displays a message similar to this:

Sorry, user tuser is not allowed to execute ‘fakecmd’ as root on myhost.example.com. 
Request rejected by Safeguard

All systems that are joined to the same policy server will have the same results based on how you have the sudoers policy file configured.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating