Open System Services Management and Operations Guide (G06.30+, H06.08+, J06.03+)

Use of suid Scripts
Some scripts, known as suid scripts, enable users to perform some activities that require appropriate
privileges; that is, the scripts could be used by an intruder to assume the identity of the super ID
(255,255 in the Guardian environment, 65535 in the OSS environment).
As a result, it is a good practice to make sure that there are no such script files on your system. As
installed, the OSS environment does not contain suid script files.
suid script files have permissions that either start with the digit 4 or have “s” as the owner’s
execution permission bit, as shown in the following example:
$ ls -l dfile
-rwxr-xr-x 1 MANUALS.HENRYP MANUALS 29 Jun 27 15:24 dfile
$ chmod 4755 dfile
$ ls -l dfile
-rwsr-xr-x 1 MANUALS.HENRYP MANUALS 29 Jun 27 15:24 dfile
You can detect suid script files by using the find command with the -perm flag, as shown in
the following example:
$ find . -perm -4000 -print
./dfile
This command searches for files that have permissions of 4000 or greater. The minus sign before
the 4000 specifies “greater than or equal to.” Files with permissions of 4000 or greater would all
be executable suid scripts. This command found such a script, named ./dfile.
For details about suid script files, consult a book about UNIX security. Some books about UNIX
security are listed in “OSS Security” (page 33).
Preventing Security Problems
To improve the security of your system:
• All OSS Monitor and server database files must always be owned by the super ID (255, 255)
and secured as having read, write, execute, and purge privileges for only the super ID (----)
in the Guardian environment.
• The /etc/install_obsolete directory and the Pcleanup command should be secured
such that only the super ID or a trusted user has access to them. A single file surreptitiously
added to /etc/install_obsolete could be used by an intruder to cause severe damage
to mounted filesets.
• The Guardian subvolume from which OSS files are installed by COPYOSS or PINSTALL should
be carefully secured and its contents periodically checked for validity. A pax archive
surreptitiously added to that subvolume could be used by an intruder to install files such as:
◦ Viruses, worms, Trojan horses, or rabbit programs
◦ Substitutes for standard utilities, containing logic bombs or back doors
• Use the -R option when starting the inetd process to reduce the chance of denial-of-service
attacks.
• Use the same security policies for FTP and remote exec services servers as you use for Telserv
terminal access. For example, the rexecd server is equivalent to a context-free, one-line
telnet session with enforced user validation; at a minimum, Safeguard should be used to
set up its users and, ideally, all requests to rexecd should be filtered by your node’s firewall.
• Do not provide network services servers such as rshd where mechanisms such as the
hosts.equiv file can be used to bypass Safeguard validations.
• For remote procedure call (RPC) applications, encourage your developers to use the application
program interface provided by the HP NonStop Distributed Computing Environment (DCE).
The authentication security is better than the AUTH_UNIX (AUTH_SYS) level authentication
Protecting Your System 227