FUP is used to manage disk files. FUP can create, display, and duplicate files, load data into files, alter file characteristics, and purge files. FUP supports these types of Enscribe disk files:
Key sequenced
Entry sequenced
Relative
Unstructured (including text files)
FUP provides information about these types of HP NonStop Kernel Open System Services (OSS) and NonStop SQL/MP files:
Tables
Indexes
Partitions
Views
Object programs
Caution | FUP has limited usage for SQL objects; only file label information can be obtained and SQL program files can be secured with FUP. NonStop SQL/MP files are managed by SQLCI. |
FUP supports Storage Management Foundation (SMF) logical file names .
The FUP Subsystem components are:
FUP
ORSERV
FUPCSTM (FUP Custom Files)
FUPLOCL (FUP Local Configuration)
FUP and ORSERV can be accessed interactively from a terminal, or pro- grammatically from a management application written in COBOL85, C, TACL, or TAL. FUP is also available as a keyword from other command interpreters, such as SQLCI.
A FUP process is created when FUP is invoked by a TACL prompt or with a RUN command. The subsequent FUP commands are interpreted and executed by the FUP process.
RISK If a user has WRITE or PURGE access to sensitive files and EXECUTE authority for the FUP object file, that user can damage or destroy sensitive data.
RISK If a user has READ access to sensitive files and EXECUTE authority for the FUP object file, that user can duplicate or display sensitive data.
AP-ADVICE-FUP-01 The best way to prevent unauthorized use of sensitive FUP commands is to secure the files properly. Because an HP NonStop server can contain a large number of files it may be extremely hard to secure them, therefore, FUP is a very dangerous utility.
The ORSERV process reloads key-sequenced Enscribe files and SQL objects. It can be accessed interactively or programmatically from a management application written in COBOL85, C, TACL, or TAL.
Although key-sequenced files can be reloaded using the interactive FUP RELOAD command, an operator must initiate, SUSPEND (when necessary), or RESUME (when appropriate) the RELOAD operation.
RISK ORSERV should only be accessible to users performing these specialized functions.
FUP reads two files (FUPLOCL and FUPCSTM) before it issues its first prompt. This allows users to customize their FUP environment before entering any commands. Both of these files are standard FUP command OBEY files that contain text with valid FUP commands.
FUPCSTM files are located on each user's default subvolume. Please refer to the Gazette section on *CSTM Configuration Files.
The FUPLOCL file is generally used to run FUP environment commands such as CONFIGURE and SET for a FUP session.
The FUPLOCL file must reside in the current SYSnn; the FUP object file's sub- volume. The file is 'shared' by all users. Whenever FUP is invoked, each command in the FUPLOCL file is executed. This enables the system administrator to configure a site-standard FUP environment.
When FUP is run on a remote node, the FUPLOCL in the SYSnn subvolume on the remote node is used.
The FUPLOCL file should be treated like a System Configuration File and secured accordingly .
RISK If the security of the FUPLOCL file permits a user other than the owner WRITE or PURGE access, they could modify the file or purge it and replace it with a new one.
RISK By default, FUP does not echo the commands so users might not even realize that destructive commands are being executed.
BP-FILE-FUPLOCL-01 Turn on echoing by specifying the CONFIGURE ECHO OBEY command in the FUPLOCL file so that the commands executed in the FUPLOCL file will be displayed.
BP-FILE-FUP-01 FUP should be secured "UUNU".
BP-OPSYS-LICENSE-01 FUP must be LICENSED.
BP-OPSYS-OWNER-01 FUP should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-01 FUP must reside in $SYSTEM.SYSnn.
BP-FILE-FUP-02 ORSERV should be secured "UUNU".
BP-OPSYS-LICENSE-01 ORSERV must be LICENSED.
BP-OPSYS-OWNER-01 ORSERV should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-01 ORSERV must reside in $SYSTEM.SYSnn.
BP-FILE-FUP-03 FUPLOCL should be secured "NUUU".
BP-OPSYS-OWNER-01 FUPLOCL should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-01 FUPLOCL must reside in $SYSTEM.SYSnn.
FUP is used extensively to set the security and run-time options on the system. With certain exceptions listed above, FUP can only operate on object files that userids have been granted access to via the Guardian or Safeguard system. Therefore, to reduce the risks associated with FUP's destructive commands secure (see below):
AP-ADVICE-FUP-02 Users should run FUP under their own userid .
AP-ADVICE-FUP-03 The secure database and other sensitive files should be secured to prevent unauthorized access to the data via FUP.
Caution | If a licensed, privileged program is opened with WRITE access, the file becomes unlicensed. |
If available, use Safeguard software or a third party object security product to grant access to FUP object files only to users who require access in order to perform their jobs.
BP-SAFE-FUP-01 Add a Safeguard Protection Record to grant appropriate access to the FUP object file.
BP-SAFE-FUP-02 Add a Safeguard Protection Record to grant appropriate access to the ORSERV object file.
BP-SAFE-FUP-03 Add a Safeguard Protection Record to grant appropriate access to the FUPLOCL file.
The following FUP commands have security implications. If a third party access control product is used to grant selected users access to FUP running as SUPER.SUPER, the sensitive commands listed in the table below should be denied to all users other than the system management or other appropriate groups.
3P-ACCESS-FUP-01 If a third party access control product is used to grant selected users access to FUP running as a SUPER.SUPER or another privileged userid such as the database owner, these sensitive commands should only be granted to the appropriate users and denied to all others.
The data in files that users can access with FUP may be sensitive. The following chart shows the file access required for certain FUP commands to be sensitive.
SUPER.SUPER Only | Owner or SUPER.SUPER [1] | READ Required | PURGE Required | Based on RWEP |
---|---|---|---|---|
LICENSE | GIVE | DUP [2] | GIVE | ALTER |
REVOKE | PROGID | COPY | PURGE | LOAD |
RENAME | PURGE | |||
PURGEDATA | ||||
RELOAD | ||||
RENAME | ||||
[1] - SUPER.SUPER can only PURGE files owned by other userids if Safeguard software is not installed or is configured SUPER.SUPER UNDENIABLE. [2] - If Safeguard software is installed the user must have CREATE access to the target file s destination volume. |
When a file is PURGED, only the file name is deleted. The extents are marked available but the data in the extents is not erased. Sensitive data could be extracted from the deleted extents. Use the CLEARONPURGE option, which physically destroys the data in the file(s) by overwriting the file space with blank data when the file is purged.
AP-ADVICE-FUP-04 Use CLEARONPURGE option on sensitive files.
Using the NOPURGEUNTIL option with a date in the future ensures that the file cannot be purged until that date even if all other security checks pass.
AP-ADVICE-FUP-05 Use NOPURGEUNTIL option on sensitive files.
The RENAME operation requires special evaluation of access authorities when Safeguard software is installed.
Access Authority Required to RENAME a File | |||||
---|---|---|---|---|---|
Current File Name | New File Name | Result | |||
Safeguard Record Exists? | Safeguard Purge Allowed? | Guardian Purge Allowed? | Safeguard Vol/Subvol/ Disk Record Exist? | Safeguard Create Allowed? | Rename Allowed? |
No | - | Yes | No | - | Yes |
No | - | Yes | Yes | Yes | Yes |
No | - | Yes | Yes | No | No |
No | - | No | - | - | No |
Yes | Yes | - | No | - | Yes |
Yes | Yes | - | Yes | Yes | Yes |
Yes | Yes | - | Yes | No | No |
Yes | No | - | - | - | No |
The Safeguard PERSISTENT attribute and RENAMING:
If the original file does not have a PERSISTENT Protection Record, the new file assumes the original file's Protection Record.
If the original file has a PERSISTENT Protection Record, the new file does not assume the original file's Protection Record.
If the new file name has a PERSISTENT Protection Record, the new file assumes the PERSISTENT Record.
Discovery Questions | Look here: | |
---|---|---|
OPSYS-OWNER-01 | Who owns the FUP object file? | Fileinfo |
OPSYS-OWNER-01 | Who owns the ORSERV object file? | Fileinfo |
OPSYS-OWNER-01 | Who owns the FUPLOCL object file? | Fileinfo |
OPSYS-LICENSE-01 | Is the FUP object file licensed? | Fileinfo |
OPSYS-LICENSE-01 | Is the ORSERV object file licensed? | Fileinfo |
FILE-POLICY | Who is allowed to execute FUP on the system? | Policy |
FILE-POLICY | Is a third party access tool used to secure FUP commands? | Policy |
FILE-FUP-01 | Is the FUP object file correctly secured with the Guardian or Safeguard system? | Fileinfo Safecom |
FILE-FUP-02 | Is the ORSERV object file correctly secured with the Guardian or Safeguard system? | Fileinfo Safecom |
FILE-FUP-03 | Is the FUPLOCL file correctly secured with the Guardian or Safeguard system? | Fileinfo Safecom |
FILE-FUPLOCL-01 | FUPLOCL file has configure echo obey turned on | Edit |
Related Topics
Securing Applications DDL
The GOAWAY utility is used to delete SQL objects or shadow labels, residing in the Guardian environment, which cannot be removed with other commands or utilities. It deletes files or file labels. GOAWAY only works on physical SQL objects, tables, indexes, views and programs.
GOAWAY is a 'last resort' tool, which is made available for sites using SQL to remove orphaned SQL objects in cases where the catalog has been damaged, corrupted, or otherwise disconnected from the SQL objects.
RISK Because GOAWAY does not delete the corresponding catalog entries, misuse of the GOAWAY utility can corrupt files.
RISK GOAWAY does not verify dependencies on the object it is purging, which can cause additional orphans.
RISK If GOAWAY is used on valid objects, data will be purged from the system that will be unrecoverable.
RISK GOAWAY does not invoke NonStop TMF commands that could undo the data on the purged objects. SQL objects purged using GOAWAY are not recoverable.
Caution | GOAWAY should never be used as a substitute for SQL DROP, PURGE, or CLEANUP operations. Always perform these as normal commands. |
BP-FILE-GOAWAY-01 GOAWAY should be secured "UUUU".
BP-OPSYS-LICENSE-02 GOAWAY must be LICENSED.
BP-OPSYS-OWNER-02 GOAWAY should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-02 GOAWAY must reside in $SYSTEM.SYSTEM
If available, use Safeguard software or a third party object security product to grant access to GOAWAY object files only to users who require access in order to perform their jobs.
BP-SAFE-GOAWAY-01 Add a Safeguard Protection Record to grant appropriate access to the GOAWAY object file.
Discovery Questions | Look here: | |
---|---|---|
OPSYS-OWNER-02 | Who owns the GOAWAY object file? | Fileinfo |
OPSYS-LICENSE-02 | Is the GOAWAY object file licensed? | Fileinfo |
FILE-POLICY | Is SQL used on the system? | Policy |
FILE-POLICY | Who is allowed to execute GOAWAY on the system? | Policy |
FILE-GOAWAY-01 | Is the GOAWAY object file correctly secured with the Guardian or Safeguard system? | Fileinfo Safecom |
Related Topics
SQL Subsystem