[Previous Section] [Back to Table of Contents] [Next Section]

IRIX Advanced Site and Server Administration Guide

Chapter 12
System Security

This chapter deals with maintaining the security of your computer system. It includes:

A great strength of the IRIX system is the ease with which users can share files and data. However, some of the security guidelines presented in this chapter are at odds with easy system access. It is up to the site administrator to balance the needs and concerns of the user community.

How Secure Is IRIX?

IRIX was never designed to be a truly secure system, but it has several features that allow you to achieve a generally acceptable level of security without adding any new software. Standard security features of IRIX are:

Security Guidelines

Computer security is the responsibility of not only the site administrator, but of everyone who has access to a computer at the site.

System users should safeguard their data by using appropriate file and directory permissions and guarding their account passwords.

Site administrators, and to some extent system users, should be aware of the following:

Logins and Passwords

System security under IRIX is primarily dependent on system login accounts and passwords. Proper administration, user education, and use of the facilities provided will yield adequate security for most sites. Most security breaches are the result of human error and improper use of the provided security features. No extra measures will yield more security if the basic features are not being used. This discussion of logins and passwords covers the following:

Managing passwords is also described in Chapter 3, "User Services."

System Login Options

For security, you can set the following login options:

Login options are set in the file /etc/config/login.options, which is a normal text file. The file contains one option specification per line. The options are described in the rest of this section.

These options are important because the login procedure is your system's main defense against unauthorized access. For example, you can determine whether someone is trying to break into your system from a pattern of failed login attempts recorded in /var/adm/SYSLOG (when logging is enabled).

Note that the best way to keep a system secure is to slow down attempts to guess passwords and account names. The login options described in this section add delays to unsuccessful login attempts, which drastically slows down the process of randomly guessing passwords.

See also the login(1) and login(4) reference pages.

Maximum Login Attempts (maxtries)

Setting this parameter slows attempts by unauthorized persons to break into a system. A common method of breaking into a system is to try to guess the password of a known account. This method is most successful if the person trying to break in knows the names of as many accounts as possible, and can make guesses very quickly. If you introduce a delay in the login process after a certain number of failed login attempts on the same tty line, you can make it much more time-consuming to guess a correct password.

To set the maximum number of login attempts, edit the file /etc/config/login.options. Place a line similar to this in the file:

maxtries=3

This sets the maximum number of login attempts to three. The system default, without this option set, is five.

When the maximum number of login attempts is exceeded, the login program sleeps for a certain number of seconds, thus preventing further login attempts on that line for a while. The system default is twenty seconds.

Length of Time to Disable a Line (disabletime)

Use this option along with the maxtries option. To set the number of seconds after a certain number of unsuccessful login attempts that a line is disabled, edit the file /etc/config/login.options and add a line similar to this:

disabletime=30

This disables a line for thirty seconds. You can choose any value you consider appropriate for your system. The system default is twenty seconds.

Recording Login Attempts

You can log both successful and unsuccessful login attempts in the file /var/adm/SYSLOG. To log all attempts to log in, place this line in the file /etc/config/login.options:

syslog=all

To log only unsuccessful attempts, place this line in the login.options file:

syslog=fail

A large number of failed logins, especially with the same account name, may indicate that someone is trying to break into the system.

Note that the visual login process pandora(1) does not provide these security options. To use the login security functions, you must turn off pandora and use the standard login processes, getty(1) and login(1). Use chkconfig to turn off the visuallogin and xdm configuration variables. See "Altering the System Configuration" and the visuallogin(4) reference page for information about turning the visual login process on and off. You may also use chkconfig to set the noiconlogin variable to disallow logging in using the user icons in pandora.

Forcing a Password

To force users who do not have passwords for their accounts to choose their passwords immediately, add this line to the file /etc/config/login.options:

passwdreq

Displaying the Last Login Time

Users can help maintain system security by noticing unauthorized use of their accounts. To help them, you can configure login to display the date and time when they last logged in successfully.

To do this, edit the file /etc/config/login.options, and add this line:

lastlog

This displays the most recent login date, time, and the name of the terminal line (tty name) or remote host from which the user logged in. This login attempt information is recorded in files, one per user account and with the same name as the account, in the directory /var/adm/lastlog.

PROM Passwords

Your system may have a facility that allows you to require a password from users who attempt to gain access to the Command (PROM) Monitor. This allows you to exercise greater control over who may perform system administration tasks and affords you some protection against severe ``denial of service'' attacks from malicious intruders. These attacks are designed not to steal your information, but to make your system useless to you.

Traditionally, if an intruder gains access to your system hardware, there is little you can do to maintain system security. In the simplest case, the intruder switches off the system, then turns it on again, and instructs the system from the console to boot a program other than your usual operating system. Alternately, the intruder could simply remove the hard disk from your machine and install it on another machine and read your files. While there is nothing you can do with system software to prevent physical theft of the hardware, you can limit the ability of intruders to boot their programs or to otherwise damage your system at its lowest levels with a PROM password.

To determine if your system supports PROM passwords, use the nvram(1M) command. Issue the command with no arguments and observe the output. The output shows the current settings of all non-volatile memory variables. If the variable passwd_key is present, your system supports PROM passwording. Alternately, you can select option 5 from the System Maintenance Menu to enter the Command Monitor. You see the Command Monitor prompt:

Command Monitor. Type "exit" to return to the menu.
>>

Enter the command:

help

The system prints a list of available commands for the Command Monitor. If the passwd command is among those listed, your system supports the PROM password. If it is not listed, your system hardware does not support passwording. If you would like to upgrade your system to support passwording, please contact your sales representative.

Setting the PROM Password Using nvram(1M)

To set the PROM password using the nvram(1M) command, perform the following steps:

    Log in as root.

    Give the following command:

    nvram passwd_key "new_password"

    In this example, only the term new_password should be replaced; the quotation marks must be used to contain the password text. Your PROM password is now set.

Note that if you forget your PROM password, but you still know your root password, you can reset the PROM password on some machines through the nvram command. If you cannot successfully reset the PROM password, you must remove the PROM or a jumper from your CPU board. See your Owner's Guide for information on this procedure.

Setting the PROM Password From the Command Monitor

If you wish to set your PROM password from within the Command Monitor, perform the following steps:

    Log in as root and shut the system down.

    When you see the message:

    Starting up the system...
To perform system maintenance instead, press <Esc>

    press the <Esc> key to see the System Maintenance Menu.

    Select option 5 from the System Maintenance Menu to enter the Command Monitor. You see the Command Monitor prompt:

    >>

    Issue the passwd command and press <Return>:

    passwd

    You see the prompt:

    Enter new password:

    Enter the password you want for your machine and press <Return>. You see the following prompt:

    Confirm new password:

    Enter the password again, exactly as you typed it before. If you typed the password the same as the first time, you will see the Command Monitor prompt again.Your password is now set. Whenever you access the Command Monitor, you will be required to enter this password.

Second (Dialup) Passwords

If your system requires additional protection, you can establish a system password. If you do this, users who log in on specific ports (ttys) are prompted for a system password in addition to their account passwords. This feature cannot be imposed on the system console, or any terminal where pandora or xdm is used.

System passwords are normally used only on dialup lines and are often referred to as dialup passwords. You can use them on standard lines, but this is usually not necessary.

To establish a system password, follow these steps:

    Log in as root.

    Edit the file /etc/dialups.

    Place in the file a list of ports (ttys) that require the second password. For example:

    /dev/ttyd1 
/dev/ttyd2 
/dev/ttyd3

    Write the file and exit the editor.

    Decide on the desired password or passwords. System passwords are assigned on a shell-by-shell basis. You can assign the same password for all the possible shells on the system, assign different passwords for each shell, or use some combination of approaches.

    Encrypt the desired password. You must use the passwd program to perform the encryption. You cannot use the crypt(1) command for this purpose.

    To encrypt the password, simply change the password of some account (for example the bin account) to the password you wish to use in /etc/d_passwd. Before you do this, note what the existing password is (or if the account is locked). You should return the account to this state when you are finished assigning a system password.

    For example, to change the password of the bin account to ``2themoon'' you enter:

    passwd bin

    You see:

    New password:

    Now enter the string ''2themoon'' and then press <Return>.The string ``2themoon'' is not displayed as you type it. Next you see:

    Re-enter password:

    Enter the string ''2themoon'' again and then press <Return>. The string is still not displayed as you type it.

    Examine the entry for the bin account in the file /etc/passwd. You should see something like this:

    bin:SaXub4uaL5NP:2:2:System Tools Owner:/bin

    The second field (between the first and second colons) is the encrypted version of the password ``2themoon.''

    Edit the file /etc/d_passwd. In the file, place lines of this form:

    shell:password:

    shell is the command interpreter (shell) you wish to have a password, and password is the encrypted password.

    For example, this assigns the password ``2themoon,'' which you encrypted in the previous step, to all C shell users who log in on the ttys specified in /etc/dialups:

    /bin/csh:SaXub4uaL5NP2:

    You must place a colon at the end of the encrypted password, and you must enter the shell program pathname exactly as it appears in /etc/passwd.

    Write the file and exit from the editor.

    Make sure the files have appropriate permissions by issuing the command:

    chmod 640 /etc/d_passwd /etc/dialups

    Remove the password you assigned to the system account in step 4. To do this, edit the file /etc/passwd and remove the string of characters in the second field. Return this field to the same state as when you began this procedure.

Now, whenever C shell users log in on the ttys specified in /etc/dialups, they are prompted for the system password ``2themoon'' in addition to their account password.

Creating a Shadow Password File

A ``shadow'' password file is simply a copy of the standard password file, but it is not accessible by non-privileged users. In the standard configuration, the /etc/passwd file is publicly readable. Since the /etc/passwd file contains the encrypted versions of the users' passwords, anyone can make a copy and attempt decryption of the passwords for malicious purposes. By invoking a shadow password file, you prevent intruders from attempting to decrypt your passwords.

The shadow password file is called /etc/shadow. Once shadow passwords have been initialized, the password field in each /etc/passwd entry is replaced by an ``x'' character.

To initialize /etc/shadow (and thus invoke shadow passwords), run the pwconv(1M) command. Once this command has been run, shadow passwords will be in effect. All standard password tools work transparently with shadow passwords. The difference should not be noticeable to your users, except that they will not be able to see the encrypted passwords in the /etc/passwd file.

One difference in system operation is that older applications will not get the proper value of pw_passwd from the getpwent(3C) and getpwnam(3C) library calls. This primarily affects ``screen saver'' programs.

Password Aging

The password aging mechanism forces users to change their passwords periodically. It also prevents a user from changing a new password before a specified time interval. You can also force a user to change his or her password immediately.

Realistically, password aging forces users to adopt at least two passwords for their accounts. This is because, when password aging is enforced, most users alternate between two passwords that they find easy to remember rather than inventing brand new passwords every time their old ones expire. IRIX does not provide a utility that determines whether users are choosing between a set of passwords and that forces them to choose completely different passwords.

Password Aging with the passwd Command

To set the maximum number of days that can elapse before a user must change his or her password, use the passwd(1) command.

For example, this command forces user alice to change her password every two weeks (14 days):

passwd -x 14 alice

If you set -x to 0, the user must change her password when it next expires, but thereafter password aging is not in effect for her. If you set -x to -1, password aging is turned off immediately for that user.

You can also set the minimum time that must elapse before users are allowed to change their passwords. This is useful to prevent users from changing their passwords, then changing them back to their old passwords immediately. For example:

passwd -x 14 -n 7 ralph

This forces user ralph to change his password every fourteen days and prevents him from changing it more frequently than once every seven days. Note that if you set the minimum value greater than the maximum value, the user may not ever change his or her password.

To force users to change their passwords immediately, use the -f option. For example:

passwd -f trixie

Using Password Aging Manually

Another way to enforce password aging is to edit the /etc/passwd file and insert the appropriate information after the password fields in the desired account entries.

Password aging information is appended to the encrypted password field in the /etc/passwd file. The password aging information consists of a comma and up to four bytes (characters) in the format:

,Mmww

The meaning of these fields is as follows:

,

The comma separates the password and the aging information.

M

The Maximum duration of the password.

m

The minimum time interval before the existing password can be changed by the user.

ww

The week (counted from the beginning of 1970) when the password was last changed and two characters, ww, are used. You do not enter this information. The system automatically adds these characters to the password aging information.

All times are specified in weeks (0 through 63) by a 64-character alphabet. The following chart shows the relationship between the numerical values and character codes. Any of the character codes can be used in the four fields of the password aging information. Table 12-1 lists the password aging codes and their meanings.

Table 12-1 : Password Aging Character Codes
Character Number of Weeks
. (period) 0 (zero)
/ (slash) 1
0 through 9 2 through 11
A through Z 12 through 37
a through z 38 through 63



Two special cases apply for the character codes:

The following shows the password aging information required to establish a new password every two weeks (0) and to deny changing the new password for one week (/) for user ralph:

ralph:RSOE2m.E,0/:100:1:Ralph P.Cramden:/usr/people/ralph:

After ralph's first login following the change, the system automatically adds the two-character, ``last-time-changed'' information to the password field:

ralph:RSOE2m.E,0/W9:100:1:Ralph P. Cramden:/usr/people/ralph:

In this example, ralph changed his password in week W9. To force ralph to change his password at the next login (and to cause this only once), you can add the code ,.. to the password field:

ralph:RSOE2m.E,..:100:1:Ralph P.Cramden:/usr/people/ralph:

After ralph changes his password, the system automatically removes the aging code (,..) from the password field. To prevent ralph from changing his password, use the code ,./. Edit the /etc/passwd file and add a comma, period, and slash to the password field:

ralph:RSOE2m.E,./:100:1:Ralph P. Cramden:/usr/people/ralph:

Now only root can change the password for the ralph account. If ralph tries to change the password, he sees the message ``permission denied.''

Locking Unused Logins

If a login is not used or needed, you should disable (lock) the login. You should not remove the account, though, because of the danger of re-using the UID in the future. User ID numbers are meant to be permanently associated with the person who used the account. If you re-use the UID number, the new user may find files that belonged to the previous owner of the ID number. These files may contain ``trojan horse'' programs that could do damage to your system. If you are extremely short on disk space, you may remove the user's home directory and files (after making a backup), but you should never remove an entry from your /etc/passwd file.

There are two ways to lock an account. The first is using the passwd command with the -l option. For example:

passwd -l norton

This command changes the password field of the entry in /etc/passwd for account norton to *LK*.

The second way to lock an account is by editing the password file directly. Change the password field to any string of characters that is not used by the password encryption program to create encrypted passwords. The passwd command with the -l option uses the string *LK*.

You can use other strings to lock accounts. For example, you can use a descriptive phrase such as ``LOCKED;'' to remind you that the account was deliberately disabled:

ralph:LOCKED;:100:1:Ralph P. Cramden:/usr/people/ralph:

The semicolon is not used in an encrypted password and causes the account to be locked. The text ``LOCKED'' is merely to remind you that the account is locked.

Another common method of disabling a password is to put an asterisk (*) in the password field. The default IRIX /etc/passwd file disables unused logins in this manner.

Special Accounts

Special accounts are used by daemons to perform system functions, such as spooling UUCP jobs and print requests. Because key files are owned by these accounts, someone who obtained access to one of the accounts, or was able to start a daemon on your system, could not completely breech security. Ownership of the various system files is distributed among the special accounts.

Guard access to all the special accounts as you would the root account. We recommend you either assign passwords to these accounts, or lock them using one of the methods described in previous sections.

The following is a list of all the administrative and special accounts on the system and what they are used for.

root

This login has no restrictions, and it overrides all other logins, protections, and permissions. It allows you access to the entire operating system. The password for the root login should be very carefully protected.

sys

This login has the power of a normal user login over the files it owns, which are in /usr/src. Its login should be disabled.

bin

This login has the power of a normal user login over the files it owns, which are throughout the system. Its login should be disabled.

adm

This login has the power of a normal user login over the object files it owns, which are located in /var/adm. You may su to the adm login. This login should be disabled.

uucp

This login owns the object and spooled data files in /usr/lib/uucp and /etc/uucp.

nuucp

This login is used by remote workstations to log into the system and initiate file transfers through /usr/lib/uucp/uucico.

daemon

This login is the system daemon, which controls background processing. Its login should be disabled.

lp

This login owns the object and spooled data files in /var/spool/lp. Its login should be disabled.

Protecting the System with Accounts and Passwords

There are several ways accounts and passwords protect the system:

Choosing Passwords

A system is most secure if nobody can access the system without an account and password, and if all the passwords on the system are difficult to guess and obtain. Surprisingly, many users choose passwords that are easy for potential intruders to guess, or write their passwords down on paper and leave them near their workstations and terminals.

Many site administrators use the same password for multiple administrative accounts. This is not a good practice. Do not deliberately use the same password for more than one account.

Good passwords are:

Bad passwords are:

Using pwck(1M) to Check the Password File

From time to time, you should run the pwck(1M) utility to scan the password file. This program reads the file and checks each entry for completeness and

notes any inconsistencies. The password checks include validation of the following items:

The default password file to be checked is /etc/passwd. If shadow passwords (described in "Creating a Shadow Password File") are enabled, the /etc/shadow file is checked.

Similarly, the grpck(1M) command verifies all entries in the /etc/group file. The default group file to be checked is /etc/group. With either command, an alternate file may be specified on the command line.

Network Security

Unless drastic steps are taken to ensure security, networks are generally quite open and thus, insecure. This section touches on some aspects of network security in addition to keeping the physical network cable safe from tampering and eavesdropping. For more information on network security, see "Planning for Network Security".

Controlling Network Access

There are three files that help you control access to a host across the network:

/etc/hosts.equiv


A list of hosts that are considered trusted, or equivalent to you.

rhosts

A list of hosts that are allowed access to a specific user account.

/etc/passwd

The list of system accounts.

These three files control whether access is granted or denied when a remote host issues an rlogin(1C), rcp(1C), rdist(1C), or rsh(1C) request.

When a request for access is received, the file hosts.equiv is checked, and if the host is listed in that file, and the target user account is listed in /etc/passwd, no further checking is performed and remote access is allowed. In this case, a remote user with a local user ID has equivalent access from a remote host.

Users can expand this equivalence by listing hosts and specific accounts in .rhosts files in their home directories. The root login bypasses the /etc/hosts.equiv file and typically uses only the /.rhosts file in the root directory for equivalence checking. If there is an entry in the /.rhosts file for root, the root user on the remote system will have root privilege on your system. For obvious reasons, this is not a secure practice. It is much more secure to handle file transfers through the non-privileged guest account.

The owner of the .rhosts file must be either the user in whose home directory it resides, or the superuser, root. If it is owned by another user, or if the file permissions allow anyone who is not the owner of the file to modify it, the contents of a user's .rhosts file are disregarded as a security practice.

For complete information about the /etc/hosts.equiv and .rhosts files, see the hosts.equiv(4) reference page.

Transparent Network Access

With the X Window System (TM) , workstations can run client programs transparently on other hosts on the network. This access is completely independent of such controls as login accounts and passwords and is done through X protocols.

By default, IRIX workstations are configured to allow complete, transparent access for all workstations on the network that use the X Window System. You can change this using the xhost(1) server access control program and the configuration file /etc/X*.hosts. In the configuration file name, the asterisk (*) corresponds to the number of the server on the local host. This is usually 0, so for most workstations the file is /etc/X0.hosts.

When the X server starts, it checks the file /etc/X*.hosts. For example, server 0 checks for /etc/X0.hosts, server 1 checks for /etc/X1.hosts, and so forth. If the file is missing, or is empty, no remote hosts are allowed access to the server. If the file contains a single plus sign (+), all remote hosts are allowed access.

Next, the xhost command is run from the file /usr/lib/X11/xdm/Xsession. In the default Xsession file, xhost is used to allow access to all remote hosts. To change the default server-access permissions, you must change how the xhost command is run from the Xsession file. Then, you can customize the /X*.host file.

The xhost program modifies the internal state of the X server. Using xhost, you can allow or deny server access for specific hosts, or for all hosts. Note that the xhost options that affect access control can be run only from the same workstation as the server.

To completely deny access to all hosts on your network through X protocols, use this command:

xhost -

To allow complete access to all hosts on your network, use this command:

xhost +

To selectively grant or deny access, specify the name of the specific host or hosts on the command line. For example, this command grants access to a host named brooklyn:

xhost +brooklyn

When granting access, the plus sign (+) is optional.

This command denies access to both brooklyn and bronx:

xhost -brooklyn -bronx

To see which hosts are currently allowed access to the server, run xhost from the command line with no options:

xhost

You can selectively allow access to remote hosts by listing their names in the /etc/X*.host file. For example, if the file /etc/X0.hosts contains the following

line, the remote hosts bronx and brooklyn are the only workstations allowed to access the local server for server 0:

bronx

In the above example, all other hosts are denied access to the local server.

The xhost command overrides the configuration file X*.host. To alter the default system configuration, you must not only modify the configuration file, but also change the xhost command in the /usr/lib/X11/xdm/Xsession file.

Note: Do not link the file X*.hosts to any other network host database, such as /etc/hosts or /etc/hosts.equiv. When the X server starts, it attempts to establish a connection to all hosts that are allowed access permission in the X*.hosts file. If this file contains a large number of hosts that are allowed access to the server, you will have to wait until connections are established with each of the hosts before the server is started.

For more information about X security and authorization, see the xhost(1), xauth(1), xserver(1), and X(1) reference pages.

Set-UID and Set-GID Permissions

The set user identification (set-UID) and set group identification (set-GID) permission bits must be used very carefully. When a user runs an executable file that has either of these permission bits set, the system gives the user the permissions of the owner of the executable file. You can add these permissions to any executable file with the chmod(1) command.

Set-UID and set-GID programs have legitimate uses, but because they are potentially harmful, there should be very few of them on your system. Beware of programs in publicly writable directories (such as /tmp, /usr/tmp.O, /var/tmp, and /usr/spool/uucppublic) that have the same name as common systems files (such as vi and rm). One reason the PATH environment variable of the root account does not include the current directory (as does the default PATH of most other users) is so that root won't accidentally execute such ``booby-trap'' programs.

System security can be compromised if a user copies another program onto a file with -rwsrwxrwx permissions. To take an extreme example, if the su command has the write access permission allowed for others, anyone can copy the shell onto it and get a password-free version of su.

The following sections provide some example commands that identify files on the system with set-UID permissions. For more information about the set-UID and set-GID bits, see the chmod(1) and chmod(2) reference pages.

Checking for Set-UIDs Owned by root

The following command line lists all set-UID files owned specifically by root:

find / -user root -perm -4000 -print

The results of this command are printed on the screen. All paths are checked starting at /, including all mounted directories. A great number of files will be found. It is up to you to scan these files for any unusual names. One possibility is to direct the output of this program to a file soon after installation and compare the results with later outputs. If this command reports any unusual files, you should investigate them immediately.

A suspicious file might turn up like this:

-r-sr-xr-x 1 root  bin   38836 Aug 10 16:16 /usr/bin/at 
-r-sr-xr-x 1 root  bin   19812 Aug 10 16:16 /usr/bin/crontab 
-r-sr-xr-x 1 root  bin   27748 Aug 10 16:16 /usr/bin/shl 
---s--x--x 1 root  sys   46040 Aug 10 15:18 /usr/bin/ct 
-r-sr-sr-x 1 root  bin   33208 Aug 10 15:55 /usr/lib/lpadmin
-r-sr-sr-x 1 root  bin   38696 Aug 10 15:55 /usr/lib/lpsched 
---s--x--- 1 root  jbond 45376 Aug 18 15:11 /usr/jbond/bin/sh 
-r-sr-xr-x 1 root  sys   11416 Aug 11 01:26 /bin/mkdir 
-r-sr-xr-x 1 root  sys   11804 Aug 11 01:26 /bin/rmdir 
-r-sr-xr-x 1 root  bin   12524 Aug 11 01:27 /bin/df 
-rwsr-xr-x 1 root  sys   21780 Aug 11 01:27 /bin/newgrp 
-r-sr-sr-x 1 root  sys   23000 Aug 11 01:27 /bin/passwd 
-r-sr-xr-x 1 root  sys   23824 Aug 11 01:27 /bin/su

In this example, the user jbond has a personal copy of /bin/sh and has made it set-UID to root. This means that jbond can execute /usr/jbond/bin/sh and become the superuser.

Checking for Set-UIDs in the Root File System

The following command line reports all files with a set-UID for the root file system (not just those owned by root): 

ls -l `/etc/ncheck -s /dev/root | cut -f2 | grep -v dev`

The ncheck(1M) command, by itself, can be used on a mounted or unmounted file system. Only the superuser may use ncheck. The normal output of the ncheck -s command includes special files.

Here, the grep command removes device files from the output. This filtering is applicable only for the root file system. The output of the modified ncheck is then used as an argument to the ls command. The file system must be mounted for the ls command to succeed. In this example output, nothing looks suspicious:

-r-sr-xr-x  1 root   bin    12524   Aug 11 01:27 /bin/df 
-rwxr-sr-x  1 root   sys    32272   Aug 10 15:53 /bin/ipcs 
-r-xr-sr-x  2 bin    mail   32852   Aug 11 01:28 /bin/mail 
-r-sr-xr-x  1 root   sys    11416   Aug 11 01:26 /bin/mkdir 
-rwsr-xr-x  1 root   sys    21780   Aug 11 01:27 /bin/newgrp 
-r-sr-sr-x  1 root   sys    23000   Aug 11 01:27 /bin/passwd 
-r-xr-sr-x  1 bin    sys    27964   Aug 11 01:28 /bin/ps 
-r-xr-sr-x  2 bin    mail   32852   Aug 11 01:28 /bin/rmail 
-r-sr-xr-x  1 root   sys    11804   Aug 11 01:26 /bin/rmdir 
-r-sr-xr-x  1 root   sys    23824   Aug 11 01:27 /bin/su 
-r-xr-sr-x  1 bin    sys    21212   Aug 10 16:08 /etc/whodo

Checking Set-UIDs in Other File Systems

This example uses the ncheck command to examine the usr file system (/dev/usr, assuming a single-disk system with default partitioning) for files that have set-UID permissions:

/etc/ncheck -s /dev/usr | cut -f2

In this partial example below, complete pathnames for the files start with /usr. /usr is not part of the ncheck output.

In this sample output, the program /usr/jbond/bin/sh should be investigated. This program is the only one in the listing of set-UID programs that is not found in a system directory. It is a command shell residing in a user's home directory. Users should, in general, not possess of set-UID binaries.

/dev/usr:
/bin/at               /bin/uux 
/bin/crontab          /lib/mv_dir 
/bin/shl              /lib/expreserve 
/bin/sadp             /lib/exrecover 
/bin/timex            /lib/accept 
/bin/cancel           /lib/lpadmin 
/bin/disable          /lib/lpmove 
/bin/enable           /lib/lpsched 
/lib/reject           /lib/lpshut 
/lib/sa/sadc          /bin/lp 
/lib/uucp/uucico      /bin/lpstat 
/lib/uucp/uusched     /bin/ct 
/bin/uucp             /bin/cu 
/bin/uuname           /lib/uucp/uuxqt 
/bin/uustat           /jbond/bin/sh

Universally Accessible Files and Directories

The following files and directories are universally available for read and write access. Depending on your site requirements, you may wish to change the permissions on these files to be more restrictive. Remember, though, that restricting permissions on historically open directories, such as /tmp, /usr/tmp.O, and /var/tmp (linked to /usr/tmp), can cause serious malfunctions in many programs, applications, and system utilities that write temporary files on behalf of users in these directories.

Accounts Shipped Without Passwords

The following accounts in your default /etc/passwd file are shipped without passwords. You should create passwords for these accounts immediately.

[Previous Section] [Back to Table of Contents] [Next Section]

Send feedback to Technical Publications.

Copyright © 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information