Previous Topic: SEOS ClassNext Topic: SUDO Class

selang Reference Guide › Classes and Properties › Classes in the AC Environment › SPECIALPGM Class

SPECIALPGM Class

The SPECIALPGM class gives specified programs special security privileges.

Each record in the SPECIALPGM class has one of two functions:

Note: When defining a program in the SPECIALPGM class, we recommend that you also define it in the FILE class. The FILE resource protects the executable by preventing someone from modifying (replacing or corrupting) the executable without authorization, and the PROGRAM resource verifies that the program does not run if it was modified when CA ControlMinder was not running.

Note: You cannot define a record in the SPECIALPGM class for incoming network interception events. This is because the incoming network interception event does not have a process name in this context. To bypass writing an audit record for the interception event, set the AUDIT property to NONE for the corresponding record in the TCP class

Use the PGMTYPE property to register system services, daemons, or other special programs.

Use the SEOSUID and NATIVEUID properties to assign a logical user to a program.

The key of the SPECIALPGM class record is a path to the special program or to a range, or pattern, of special programs.

Note: The maximum number of rules that you can place in the specialpgm class table is 512.

The following definitions describe the properties contained in this class record. Most properties are modifiable and can be manipulated using selang or the administration interfaces. Non modifiable properties are marked informational.

COMMENT

Defines additional information that you want to include in the record. CA ControlMinder does not use this information for authorization.

Limit: 255 characters.

CREATE_TIME

(Informational) Displays the date and time when the record was created.

NATIVEUID

Indicates the user invoking the program or process. Use * to specify all CA ControlMinder users.

Use the nativeuid parameter with the chres, editres, or newres command to modify this property.

Note: For backward compatibility with older versions of CA ControlMinder, you can use the UNIXUID property instead of the NATIVEUID property.

OWNER

Defines the user or group that owns the record.

PGMTYPE

Determines the types of access checks that CA ControlMinder bypasses when granting access.

backup

Bypasses READ, CHDIR, and UTIME access.

Note: There are two ways to run a successful backup. If the backup program is executed by a non-root user, you have to define this user as an OPERATOR. If the backup program is executed by root, it is enough to register the backup program in the SPECIALPGM class as pgmtype(backup).

changeid

(UNIX only) Bypasses all the change identity tools except for the PAM enabled surrograte tool.

For example: er specialpgm /bin/mail pgmtype(changeid)

dcm

(Windows) Bypasses all security checks for all events except STOP events.

(UNIX) Bypasses security checks for READ and EXEC events.

fullbypass

Fully bypasses all CA ControlMinder authorization and database checks. CA ControlMinder ignores a process that has this property, and no record of any process events appears in CA ControlMinder audit, trace, or debug logs.

kill

(Windows only) Bypasses program termination for a process.

For example, the following rule provides a bypass to the services.exe if this process tries to open handles to CA ControlMinder services (processes) with access mask KILL:

nr specialpgm c:\Windows\system32\services.exe pgmtype(kill)

On Windows Server 2008, the services.exe process, which manages the stopping and starting of services, opens handles to CA ControlMinder services (processes) with access type KILL to manage process termination and startup. During installation on Windows Server 2008, CA ControlMinder runs a discovery process to locate services.exe and creates a bypass rule for it. Without this bypass, you will receive DENIED CA ControlMinder audit events when services.exe is trying to open handles of CA ControlMinder services.

mail

(UNIX only) Bypasses database checks for setuid and setgid events. The mail bypass allows you to trace mail access attempts.

none

Removes any PGMTYPE previously set.

pbf

Bypasses database checks for file handling events.

pbn

Bypasses database checks for network-related events.

propagate

Propagates its own security privileges to any programs that are called from a program with this PGMTYPE. If you do not specify this, SPECIALPGM privileges only affect the parent program. SPGM batch files, including propagate, are supported for executables only.

Note: Security privilege propagation works with PBF, PBN, DCM, FULLBYPASS, and SURROGATE privileges only.

registry

(Windows only) Bypasses database checks for programs that manipulate the Windows registry.

stop

Bypasses database checks for the STOP feature.

surrogate

Bypasses database checks for identity changing events in the kernel. You cannot trace if you use the surrogate bypass.

xdm

(UNIX only) Bypasses network events (such as TCP, HOST, and CONNECT classes) for a limited network range (6000-6010).

Use the pgmtype parameter with the chres, editres, or newres command to modify this property.

SEOSUID

Defines the surrogate logical user authorized to run this special program. This logical user must be defined in the database with a USER record.

Use the seosuid parameter with the chres, editres, or newres command to modify this property.

UPDATE_TIME

(Informational) Displays the date and time when the record was last modified.

UPDATE_WHO

(Informational) Displays the administrator who performed the update.

Example: Protect a UNIX file

To protect a file that resides in /DATABASE/data/*, the Database Manager uses a file server daemon named firmdb_filemgr. This file server resides on /opt/dbfirm/bin/firmdb_filemgr. This daemon usually runs under root, making the data accessible to any root‑shell hack.

In the following example, the logical user is defined as the only accessor of these files; access by others is restricted:

  1. Define the “sensitive” files to CA ControlMinder using the command: 
    newres file /DATABASE/data/* defaccess(NONE)owner(nobody)
  2. Define the logical user to access the files: 
    newusr firmDB_mgr
  3. Allow only the logical user firmDB_mgr to access the files. 
    authorize file /DATABASE/data/* uid(firmDB_mgr) access(ALL)
  4. Finally, make firmdb_filemgr run with logical user firmDB_mgr 
    newres SPECIALPGM /opt/dbfirm/bin/firmdb_filemgr unixuid(root) \
seosuid(firmDB_mgr)

Consequently, when the daemon accesses the files, CA ControlMinder recognizes the logical user as the accessor of the files, and not root. A hacker who attempts to access the files as root does not succeed.

Example: Protect a Windows file

To protect files that reside in C:\DATABASE\data, the Database Manager uses a file server service named firmdb_filemgr.exe. This file server resides on C:\Program Files\dbfirm\bin\firmdb_filemgr.exe. This service usually runs under the system account, making the data accessible to any system hack.

In the following example, the logical user is defined as the only accessor of these files; access by others is restricted:

  1. Define the “sensitive” files to CA ControlMinder using the following command: 
    newres file C:\DATABASE\data\* defaccess(NONE)owner(nobody)
  2. Define a logical user to access the files: 
    newusr firmDB_mgr
  3. Allow only the logical user firmDB_mgr to access the files: 
    authorize file C:\DATABASE\data\* uid(firmDB_mgr) access(ALL)
  4. Finally, make firmdb_filemgr run with logical user firmDB_mgr: 
    newres SPECIALPGM ("C:\Program Files\dbfirm\bin\firmdb_filemgr.exe") \
nativeuid(system) seosuid(firmDB_mgr)

Consequently, when the service accesses the files, CA ControlMinder recognizes the logical user as the accessor of the files, and not the system account. A hacker who attempts to access the files in the system account does not succeed.