Using PowerBroker for root delegation

You can choose the PowerBroker root delegation tool when configuring a Unix authentication record. Just configure the "pb.conf" file to allow the user account provided in the Unix authentication record to execute commands with root access on the hosts to be scanned.

What PowerBroker version is supported?

BeyondTrust PowerBroker version 6.0 is required.

PowerBroker supports multiple Unix/Linux platforms. The following technology platforms have been verified for successful PowerBroker integration with our security service: Red Hat Ent Linux v3, v4, and v5.x, SUSE Linux Ent Server 9, 10, and 11, HP-UX 11i v1, v2, and v3, IBM AIX v5.x and 6.x, SUN Solaris 8, 9, and 10, VMware ESX 3.x and 4.x, Mac OS 10.x.

What credentials should I use?

This depends on the type of scanning you plan to do. We recommend you review what credentials are needed for scanning.

Are "run hosts" supported?

Yes, we support scanning "run hosts", not "submit hosts".

How does root delegation work?

When PowerBroker is properly configured within a Unix record, Unix authentication to hosts in the record works like this 1) we'll authenticate to the hosts using the login credentials provided in the record (user name and password, RSA key or DSA key), 2) we'll execute the command "pbrun su -" to obtain root authority, and 3) we'll perform commands with root authority to complete the scan.

pb.conf file

You must include "runuser = root" in the pb.conf file. If this entry is commented out, then authentication with root access will fail.

Recommended pb.conf settings:

We use "qualys" to refer to the PowerBroker user created for scanning with our service.

- Constrain "qualys" to PowerBroker requests to just "su -". This way the production policy does not permit the "qualys" user to issue just any privileged command.

- Make sure the "qualys" user gets delegated the system "su" binary. We set the PATH environment variable in the policy to manage this. So even when the user types in "pbrun /a/b/c/mine/su -" or points their PATH to a special directory that has an "su" executable, PowerBroker will delegate the correct system "su" binary.

- Make sure that the policy delegates "su -" to the "qualys" user, and not "su - oracle" or other forms of "su" requests to some other privileged user.

- Enable logging in your iolog file. Point the "iolog" variable to a directory that exists in the PowerBroker loghost. This iolog file can provide the validating information showing that your application executed only the commands it needed and at the same time potentially provide you with a "debugging" mechanism should your application not run correctly. For debugging purposes, the iolog file can be used to replay a PowerBroker session using this command: pbreplay <log file>

- Make use of a more secure policy to delegate "su -".

Samples

Check out these PowerBroker pb.conf file samples to learn about configuration settings.

Sample 1 - Delegate "su_" using user "qualys"Sample 1 - Delegate "su_" using user "qualys"

The policy below delegates "su -" using the hardcoded user "qualys".

# verify that the user is "qualys" and the request is "su -"
if (user == "qualys" && basename(command) == "su" &&
   argc == 2 && argv[1] == "-") {
   # set the user runtime properties of the delegated command and PATH
   runuser = "root";
   setenv("PATH", "/bin:/usr/bin:/sbin:/usr/bin");
   # capture the resulting session in an iolog file
   # note: the path to the iolog file might need to be customized
   iolog = "/var/log/pb.iolog." + user + "." + basename(command) + "." +
           strftime("%y%m%d.%H%M%S");
   # accept this authorized "su" command
   accept;
}

 

Sample 2 - Validate the user info from an external sourceSample 2 - Validate the user info from an external source

The sample below validates the "user" information from an "external' source such as a text file instead of a hardcoded policy entry.

# define a list of "authorized users"
authorized_users_list = split(readfile("/etc/pb/authorized_qualsys_account"), "\n");
# verify that the submitting user is one of many authorized users and the request is "su -"
if (user in authorized_users_list && basename(command) == "su" &&
   argc == 2 && argv[1] == "-") {
   # set the user runtime properties of the delegated command and PATH
   runuser = "root";
   setenv("PATH", "/bin:/usr/bin:/sbin:/usr/bin");
   runcommand = basename(command);
   # capture the resulting session in an iolog file
   # note: the path to the iolog file might need to be customized
   iolog = "/var/adm/pb.iolog." + user + "." + basename(command) + "." +
           strftime("%y%m%d.%H%M%S");
   # accept this authorized "su" command
   accept;
}

 

Sample 3 - Control the size of the iolog fileSample 3 - Control the size of the iolog file

To control the "size" of the iolog file, you can add the policy variable "logstdoutlimit". Add the following under the "iolog" entry in the policy.

# put upperbound limits on the size of the captured data
logstdinlimit = 5000;
logstdoutlimit = 5000;
logstderrlimit = 5000;

 

Sample 4 - Log only the input stream and limit captured data to 10KSample 4 - Log only the input stream and limit captured data to 10K

If the requirement is to log only the input stream and at the same time put an upper bound of 10K on the captured data, add the following under the "iolog" entry in the policy.

# only capture data from standard input and cap the captured data to 10K
logstdout = false;
logstderr = false;
logstdinlimit = 10000;