PROGID d Files


PROGID'd Files

A process's Creator ID (CAID) is the userid of the user who initiated the process's creation.

A process's Accessor ID (PAID) identifies the process and is used to determine if the process has authority to make requests of the system such as accessing a file or stopping another process.

Normally, when a process is created, the PAID of the creator process becomes the new process's CAID and the new process adopts the PAID of its creator. So when a user starts a program, the program runs as the user of the invoking program, with that user's privileges and is able to access those resources to which that user has been granted access.

But PROGIDing the running process's object file causes the running process to take the userid of the owner of the program object file instead of the invoker's userid, thus gaining the owner's privileges and access to resources.

PROGID is set using the FUP System Utility program.

PROGID is the equivalent of SETUID on Unix systems.

RISK When the PROGID attribute of a program is ON, any process created from that PROGID'd program file runs with a PAID equivalent to the program file owner's userid, not the PAID of the creating process.

RISK If the PROGID'd program is owned by SUPER.SUPER, and users can run this program, the running program gains all the privileges of SUPER.SUPER.

Caution

Without a third party access control product which can grant audited access to privileged files and data, PROGID is the only way for users to perform certain tasks required by their job or another privileged userid, such as doing system backups or managing application jobs, without either being aliased to or logging on as a SUPER Group member or some other privileged userid.

Certain third party products may require that certain of their programs or library files be PROGID'd. The necessary documentation should be provided by the vendor.

RISK When a user starts a PROGID'd program, that user temporarily gains another user's privileges without any auditing.

RISK PROGID is particularly dangerous if the PROGID'd program has a RUN command because any processes started will also run as the owner of the PROGID program file, gaining all that PROGID'd users privileges.

RISK The input and output files for the PROGID process are opened using the userid that set the PROGID rather than the CAID. Safeguard and Guardian disk security rules will be applied with the PROGID userid rather than the CAID.

Utilities with embedded RUN commands start the subordinate RUN programs using the PROGID userid rather than the CAID. These programs include:

EDIT

TEDIT

SCF

FUP

SAFECOM

SQLCI

ENFORM (Can only RUN EDIT from within ENFORM)

BATCHCOM (RUN command and users can queue up batch jobs; Another kind of RUN command)

PATHCOM (Users who can ADD and START a server have a RUN command)

RISK Without a third party Access Control Product, there is no way to prevent users from using the FUP command to PROGID an object file.

The list of allowable PROGID'd programs must be closely monitored .

Securing PROGID'd Files

Verify that there are policies in place regarding the authorization of PROGID programs and that procedures exist to evaluate the reason for the PROGID and its function before authorizing the PROGID'd state.

There are four phases necessary to ensure that the system is not vulnerable to unauthorized PROGID'd programs or unauthorized use of approved PROGID'd programs:

Documentation and Authorization of PROGID'd programs.

Secure PROGID'd programs.

Controlling the PROGID command

Scheduled Review for Unauthorized PROGID'd Files

Documentation and Authorization

RISK PROGIDing in-house programs can inadvertently grant unwanted access to application and system objects.

AP-PROGID-POLICY-01 PROGIDing in-house programs is not recommended.

AP-PROGID-POLICY-02 User's actions within programs should be trackable to their unique userid.

3P-ACCESS-ADVICE Third party access control products can provide access to utilities running as appropriate Job Function or Application Owner IDs as well as granular permission to use certain commands within the utilities. These products also audit user actions within the utilities.

If in-house PROGID programs are used, the Corporate Security Policy and Standards should include the instructions for managing PROGID requests for in-house programs.

Create procedures to review and document all requests to PROGID programs should include:

  1. The request for PROGID should include a full explanation of the program's purpose and a justification of the use.

  2. The system manager or a trusted programmer must review the program's function. The reviewer should look for security requirements of the program:

    Verify that the task cannot be achieved without using PROGID.

    Verify that the owner of the PROGID'd program is appropriate for the task.

  3. Management must approve the licensing in writing with approved signature(s).

  4. To assure that the source code matches the actual object program, the system manager, not the developer, should compile and bind the final program.

  5. The program must be tested to ensure that it does not perform or allow any actions that would be considered security violations. This test is usually performed by the Security staff.

  6. The above document should be maintained in a file for future reference by auditors .

  7. Requests for PROGIDing user programs may be allowed if the following conditions are met:

    1. The function is legitimate and necessary.

    2. The function cannot be achieved using other programming techniques.

Protecting Against Authorized Use

PROGID'd object files must be tightly secured to prevent security breaches.

Secure PROGID'd programs so that only authorized users can execute them.

RISK If PROGID'd programs reside in $SYSTEM.SYSTEM or $SYSTEM.SYSnn, they will be accessible to the general user population which normally is granted EXECUTE access to the programs in these subvolumes via Safeguard SUBVOLUME Protection Records.

AP-PROGID-POLICY-03 PROGID'd programs should not reside in $SYSTEM.SYSTEM or $SYSTEM.SYSnn.

AP-PROGID-POLICY-04 PROGID'd programs should not reside in sub- volumes that do not have a Safeguard SUBVOLUME Protection record, especially those subvolumes in the PMSEARCHLIST.

PROGID'd Operating System Programs

The following tables list the allowable PROGID'd programs that may be present in the HP NonStop server operating system. According to the CUSTFILE, no HP operating system files require PROGID. However, normal practices of certain subsystems recommend that certain object files be PROGID'd.

The tables are current as of Release Version Update G06.18.

Table 4: Lists the files on the $SYSTEM volume.

PROGID'd Operating System Files on the $SYSTEM volume.

Program Name

Description

BP-OPSYS-PROGID-01

BACKUP
RESTORE

User program (Should never reside in $SYSTEM.SYSnn) User program (Should never reside in $SYSTEM.SYSnn)

BP-OPSYS-PROGID-02

JOB
SSGCOM
ASAP

NetBatch subsystem HP Support interface ASAP application files

BP-OPSYS-PROGID-04

BACKUP
CBEXE RESTORE
TZEXE

User program (If Policy allows) DSMSCM object file User program (If Policy allows)) DSMSCM object file

PROGID'd Third Party Programs

When installing third party products, the vendor may require that some of their programs or library files be PROGID'd. The necessary documentation should be provided by the vendor.

AP-PROGID-POLICY-05 The vendor of any third party product should provide guidelines for securing the PROGID'd programs included in their software packages as well as the necessary documentation of the program's usage.

Controlling Use of the PROGID Command

Safeguard software does not generate DISKFILE audits based on the PROGID OPERATION, even if the files are PROGID'd using Safeguard software instead of FUP. This OPERATION parameter in the Safeguard Audit Layout is 'reserved for future use'.

RISK Without a third party Access Control Product, there is no way to audit the FUP SECURE, PROGID command.

With a third party access control product:

3P-ACCESS-PROGID-01 Use a third party access control product to allow the users responsible for using PROGID the ability to run the command in FUP as SUPER.SUPER.

3P-ACCESS-PROGID-02 Use a third party access control product to give the use of certain FUP PROGID commands to a limited group of users only.

Without a third party access control product:

The only way to audit the PROGIDing of a file is to force Safeguard software to audit all changes to a diskfile's Protection Record. To obtain the audit, all of the following must be true:

The target file must have a Safeguard DISKFILE ACL.

The AUDIT-MANAGE-PASS attribute must be a value other than NONE.

The Safeguard ALTER DISKFILE <filename>, PROGID ON command must be used.

Caution

This method is hardly feasible , as every object program would need a DISKFILE Protection Record.

Scheduled Review for Unauthorized PROGID'd Files

Routinely monitor the system for PROGID'd object files. Catalog authorized PROGID'd files and monitor for unauthorized uses of PROGID.

BP-POLICY-PROGID-01 Routinely monitor for unauthorized PROGID'd files.

BP-POLICY-PROGID-02 Remove unauthorized PROGID'd files.

BP-POLICY-PROGID-03 PROGID'd files owned by SUPER.SUPER should be closely monitored.

BP-POLICY-PROGID-04 PROGID'd files should be secured correctly. Specific security requirements have been given throughout this section. If not otherwise covered, the security should be "UUCU"

BP-POLICY-PROGID-05 Control the use of the PROGID command in FUP.

Discovery Questions

Look here:

FILE-POLICY

Are any PROGID'd files authorized on the system?

Policy

OPSYS-PROGID-01

Do any PROGID'd programs reside in $SYSTEM.SYSnn?

DSAP Fileinfo

OPSYS-PROGID-02

Do any PROGID'd programs reside in $SYSTEM.SYSTEM?

DSAP Fileinfo

OPSYS-PROGID-03

Do any PROGID'd programs reside in $SYSTEM.<svol>?

DSAP Fileinfo

OPSYS-PROGID-04

Do any PROGID'd programs reside in $<vol>.<svol>?

DSAP Fileinfo

OPSYS-OWNER-01

Are any PROGID'd programs in $SYSTEM.SYSnn owned by SUPER.SUPER

Fileinfo

OPSYS-OWNER-02

Are any PROGID'd programs in $SYSTEM.SYSTEM owned by SUPER.SUPER

Fileinfo

OPSYS-OWNER-03

Are any PROGID'd programs in $SYSTEM.<svol> owned by SUPER.SUPER

Fileinfo

OPSYS-OWNER-04

Are any PROGID'd programs in $<vol>.<svol> owned by SUPER.SUPER

Fileinfo

FILE-POLICY

Is each PROGID'd file secured against unauthorized use with either the Guardian or Safeguard system?

Fileinfo

OPSYS-PROGID-01 OPSYS-PROGID-02

The following list of files should not be PROGID'd. Are any of the following object files PROGID'd?
EDIT
TEDIT
SCF
FUP
SAFECOM
SQLCI
ENFORM
BATCHCOM
PATHCOM
TACL

Fileinfo Safecom

FILE-POLICY

A e policies and procedures in place to document the PROGID'd programs on the system?

Policy

FILE-POLICY

Are policies and procedures in place to periodically review the PROGID'd programs on the system?

Policy

Related Topics:

Securing DISKFILES With Guardian System

Securing DISKFILES With Safeguard Subsystem

FUP




HP NonStop Server Security 2004
HP NonStop Server Security 2004
ISBN: 159059035X
EAN: N/A
Year: 2004
Pages: 157

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net