Role Based Policy

Role Based Policy has been implemented to simplify the definition of policy for administrators. Policies are kept within structured records in a database, simplifying maintenance, decreasing system load, increasing throughput, and providing a comprehensive REST API to integrate policy management with existing customer systems and procedures, including simplified bulk import/export of data. Once the customers' data is held within the Role Based Policy database it is much easier to provide management information, such as user entitlement reports. The policy data is grouped into users, hosts, commands, time/dates, and roles detailed in the schema below.

Database Schema

User Groups

User Groups define groups of users and/or wildcard patterns that match usernames:

CREATE TABLE usergrp ( 
   id INTEGER PRIMARY,
   name TEXT,
   description TEXT,
   disabled INTEGER CHECK(disabled BETWEEN 0 AND 1), -- 0=enabled, 1=disabled 
   type CHAR(1) CHECK (type IN ('I','E')), -- I=Internal, E=external
   single INTEGER CHECK(disabled BETWEEN 0 AND 1),
   extinfo TEXT,  -- external lookup info 
   UNIQUE {name, id));

CREATE TABLE userlist (
   id INTEGER
   user TEXT, -- "glob" wildcard
   PRIMARY KEY(id,user),
   FOREIGN KEY(id) REFERENCES usergrp(id) DEFERRABLE INITIALLY DEFERRED);

Each user group has multiple user list entries that specify names and/or wildcards that match both submit and run user names when matched by the role.

There is additionally a special value user list entry that allows the Role Based Policy to match on the specified submit username, that is $submituser$.

An image of User Group and Membership List values in Endpoint Privilege Management for Unix and Linux.

Host Groups

Host groups define groups of hosts and/or wildcard patterns that match hostnames:

CREATE TABLE hostgrp ( id INTEGER PRIMARY, name TEXT UNIQUE,
description TEXT,
disabled INTEGER CHECK(disabled BETWEEN 0 AND 1), -- 0=enabled, 1=disabled 
type CHAR(1) CHECK (type IN ('I','E')),           -- I=Internal, E=external
extinfo TEXT                                      -- external lookup info

CREATE TABLE hostlist (
id INTEGER REFERENCES hostgrp(id), host TEXT,     -- "glob" wildcard
PRIMARY KEY(id,host)
);

Each host group has multiple host list entries that specify names and/or wildcards that will match both submit and run host names when matched by the role.

An image of Host Group and Host List values in Endpoint Privilege Management for Unix and Linux.

Command Groups

Command groups define groups of commands and/or wildcard patterns that match commands:

CREATE TABLE cmdgrp (
id INTEGER PRIMARY, name TEXT UNIQUE,
description TEXT,
disabled INTEGER CHECK(disabled BETWEEN 0 AND 1) -- 0=enabled, 1=disabled
);

CREATE TABLE cmdlist (
id INTEGER REFERENCES cmdgrp(id),
cmd TEXT,                                        -- "glob" wildcard
rewrite TEXT,                                    -- new command (see below)
PRIMARY KEY(id,cmd)
);

Each command group has multiple command list entries that specify commands and/or wildcards that will match the submitted command name when matched by the role, and a rewrite column to rewrite the command that will executed. The rewrite is in a similar format to Bourne/Bash shell arguments. For example, $0, $1, etc, $* and $#. Rewrite uses the original command to substitute arguments into the new rewritten command.

Command Group and Command List values in Endpoint Privilege Management for Unix and Linux

Time/Date Groups

Time/date groups define groups of times/dates and/or wildcard patterns that match times/dates:

CREATE TABLE tmdategrp (
id INTEGER PRIMARY,
name TEXT UNIQUE,
description TEXT,
disabled INTEGER CHECK(disabled BETWEEN 0 AND 1)   -- 0=enabled, 1=disabled

CREATE TABLE tmdatelist (
id INTEGER REFERENCES tmdategrp(id),
tmdate TEXT,                                       -- json format - see below
PRIMARY KEY(id,tmdate)
);

Each time/date group has multiple time/date list entries that specify times/dates and/or wildcards that match the submitted command name when matched by the role, and a rewrite column to rewrite the command that is executed. Each individual time/date is specified in JSON format, and can be one of two different formats:

  • From/To specific date range: from and to are specified in epoch seconds:
    '{ "range" : { "from" : 1415851283, "to": 1415887283 }}'
  • Day of the Week: each day is specified as an array of hours. Each hour is a number representing 15 minute intervals defined as a binary mask:
    1 1 1 1
^ 0 to 14 minutes of the hour
^-- 15 to 29 minutes of the hour
^---- 30 to 44 minutes of the hour
^------ 45 to 59 minutes of the hour Therefore the values range from 0 to 15:

'{
"mon" : [0,0,0,0,0,0,0,15,15,15,15,15,15,15,15,15,15,15,3,0,0,0,0,0,0],
"tue" : [0,0,0,0,0,0,0,15,15,15,15,15,15,15,15,15,15,15,3,0,0,0,0,0,0],
"wed" : [0,0,0,0,0,0,0,15,15,15,15,15,15,15,15,15,15,15,3,0,0,0,0,0,0],
"thu" : [0,0,0,0,0,0,0,15,15,15,15,15,15,15,15,15,15,15,3,0,0,0,0,0,0],
"fri" : [0,0,0,0,0,0,0,15,15,15,15,15,15,15,15,15,15,15,3,0,0,0,0,0,0],
"sat" : [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
"sun" : [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
}'

An image of Time/Date Group and Time/Date List values in Endpoint Privilege Management for Unix and Linux.

Roles

Roles are the entities that tie all the other entities together to define a role.

CREATE TABLE role (
id INTEGER PRIMARY KEY,
name TEXT UNIQUE,
rorder INTEGER,                                    -- rule order for matching
description TEXT,
disabled INTEGER CHECK(disabled BETWEEN 0 AND 1),  -- 0=enabled, 1=disabled
risk INTEGER CHECK(risk >= 0),
action CHAR(1) CHECK (action IN ('A','R')),        -- A=Accept, R=Reject
iolog TEXT,         -- iolog template
script TEXT,        -- pbparse script
tag TEXT,           -- Arbitrary tag that will allow grouping of roles
comment TEXT,       -- Arbitrary comment field that can contain anything
message TEXT,       -- Accept/reject message (templated)
variables TEXT,     -- Contains JSON formatted Policy Script variables to set (templated)
varmatch TEXT,      -- Contains JSON formatted Policy Script variables to match
auth TEXT,          -- Contains JSON formatted array of authentication methods (templated)
rpt INTEGER DEFAULT 1     -- 1=on, 0=off, include Role in Entitlement Report
);

CREATE TABLE roleusers (
id INTEGER REFERENCES role(id),
users INTEGER REFERENCES usergrp(id),
type CHAR(1) CHECK (type IN ('S','R')),          -- S=Submit, R=Run User
PRIMARY KEY (id,users,type)
);

CREATE TABLE rolehosts (
id INTEGER REFERENCES role(id),
hosts INTEGER REFERENCES hostgrp(id),
type CHAR(1) CHECK (type IN ('S','R')),          -- S=Submit, R=Run Host
PRIMARY KEY (id,hosts,type)
);

CREATE TABLE rolecmds (
id INTEGER REFERENCES role(id),
cmds INTEGER REFERENCES cmdgrp(id),
PRIMARY KEY (id,cmds)
);

CREATE TABLE roletmdates (
id INTEGER REFERENCES role(id),
tmdates INTEGER REFERENCES tmdategrp(id),
PRIMARY KEY (id,tmdates)
);

Each role has multiple users, hosts, commands and time/dates. When the Policy Engine matches against roles, complete records are selected from the database as fully populated roles, sorted by the role attribute rorder. Once the first record has been matched, the attributes of the role are applied to the session, and the Policy Engine either accepts or rejects the session. The iolog template is the normal script format log file, for example /var/log/io_ log.XXXXXX. The script is a full EPM-UL script that is called if the role has been accepted. This script can carry out extra processing to authorize the session (and can therefore override the accept/reject status with an implicit command), and can carry out extended environment configuration as would normal EPM-UL script.

An image of Role, User, Host, Command, and Time/Date List values in Endpoint Privilege Management for Unix and Linux.

Change Management Events

There are two different approaches to maintaining the Role Based Policy database. The first, simple method is to access the tables using pbdbutil at the command line. Each change is individual, instantaneous, and live immediately. Although for smaller organizations this is adequate, larger organizations have a more controlled procedural access method.

Role Based Policy database change transactions can be enabled using the settings rbptransactions. Once enabled, before changes can be made, the administrator must begin a change transaction, specifying a reason why the change is being made. This is logged and the whole Role Based Policy database is then locked for update. Only that administrator can continue to make changes.

These changes will NOT be mirrored in the live authorization process and can continue to be made by that administrator alone, and when completed can be committed or rolled back. Once the changes are committed they are all applied to the database as one update, and a change management event is generated. If the changes are rolled back, they are discarded and nothing changes.

If a change transaction is begun, and the administrator leaves it open and fails to close the transaction, any other administrator with access can force the rollback of the changes. This requires specifying a reason, and logs a change management event. The change transactions are necessary once the GUI policy updates are implemented to force database integrity.

To enable the logging of change management events, each client needs to configure the pb.setting changemanagementevents yes, log servers need to define eventdb <path>, and the REST pbconfigd service must be running.

For more information on Role Based Policy Options and Descriptions, see Role Based Policy Options .