Open System Services Management and Operations Guide (G06.25+, H06.03+)
Managing Security
Open System Services Management and Operations Guide—527191-002
8-28
Preventing Security Problems
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 UNIX Security on page xix.
Preventing Security Problems
To improve the security of your system:
•
All OSS Monitor and server database files should 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.