## Documents for filesys

Code [fsys001f]

The listed file is a setuid script. On most UNIX machines, it is not possible to write a secure setuid script, due to a race condition in the Operating System. Even on systems where this is corrected, the difficulties in writing a truly secure setuid script make them very undesirable. The setuid bits should be turned off of this file.

If you must run a script under another id, then perhaps the best solution is to write a wrapper program in C which creates a safe environment for the script, then exec()'s it.

Code [fsys002w]

The listed program is a setuid executable, and it appears to contain relative pathnames (do not start with a '/'). This often represents a security hole in the program. These relative pathnames can be caused by system()* or popen()* calls which do not use full pathnames to the executable, or, on systems which support dynamic linking, relative pathnames indicating the directories containing the libraries. In any case, these need to be checked.

*Note: system() and popen() should *never* be used from a program which is executing with privileges.

Code [fsys003c]

The database of setuid programs for this platform does not exist, thus all setuid programs will be listed. When fully configured for a platform, only those setuid programs that do not appear in the distribution will be listed.

Code [fsys004a]

The listed programs are setuid, but are not in the database of setuid programs which appear in the OS distribution.

Code [fsys005a]

The listed file has an unusual filenames. These include files with multiple leading '.', filenames with spaces, etc. The variable FS_FILES can be set in the 'tigerrc' file to specify the filename patterns which are reported.

Code [fsys006a]

The listed files are device files that are located in non-standard locations. These should be checked. The variable FS_DEVDIRS can be set in the 'tigerrc' file to specify other directories which can contain device files.

Code [fsys007i]

The indicated file is a symbolic link to a system file which is related to system security. In itself, the link is not dangerous, but you should be aware of its presence, as it can cause unexpected results with the 'chown' and 'chmod' commands. On many systems, the 'chown' command does not change the owner of the link itself, but instead, changes the ownership of the file the link resolves to. The same type of problem exists for 'chmod' on most systems. Thus, the simple act of performing a

chown -R joeuser /home/joeuser

could potentially change the owner of a system file to 'joeuser'.

Code [fsys008f]

The listed directories are world writable. These provide a location for intruders to store files. They should be checked for unusual files.

Code [fsys009w]

An FSP server control file has been located. This indicates that an FSP server may be running, or have been running, using the directory containing the listed file as its base.

Code [fsys010w]

The listed file is a setgid script. On most UNIX machines, it is not possible to write a secure setgid script, due to a race condition in the Operating System. Even on systems where this is corrected, the difficulties in writing a truly secure setgid script make them very undesirable.

Code [fsys011a]

The listed programs are setgid, but are not in the database of setgid programs which appear in the OS distribution.

Code [fsys012w]

The listed program is not owned by an administrative user. The majority of SUID programs should probably be owned by an administrative user.

Code [fsys013w]

The symbolic link points to a file that does not exist in the filesystem. In itself, the link is not dangerous, but you should be aware of its presence, as it might be related to an abnormal situation or system misconfiguration. You can safely ignore this information if it is related to a remotely mounted filesystem (e.g. NFS) since symlinks in remote filesystems might be valid only on the system that exports it.

Code [fsys014w]

The file does not belong to any user. It is owned by a numeric UID which is not defined in the system. This might have happened due to a user being removed from the system and the files that were owned by this user have not been removed. In this case, if a new user is created in the system matching this user ID he will inmediately own the orphaned files.

This circumstance might also show up if the user database is not fully defined locally (i.e. some of it is in an external repository such as an LDAP). If this is the case you can safely ignore this warning.

Code [fsys015w]

The file does not belong to any group. It is owned by a group UID which is not defined in the system. This might have happened due to a group being removed from the system and the files that were owned by this group have not been removed. In this case, if a new group is created in the system matching this group ID, the users belonging to this group will inmediately own the orphaned files.

This circumstance might also show up if the group database is not fully defined locally (i.e. some of it is in an external repository such as an LDAP). If this is the case you can safely ignore this warning.