Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

SGI security Frequently Asked Questions (FAQ)
Section - -3- How can I configure IRIX to be more secure?

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum ]

Top Document: SGI security Frequently Asked Questions (FAQ)
Previous Document: -2- How can I check my system for security problems?
Next Document: -4- How can I log more information about logins?
See reader questions & answers on this topic! - Help others by sharing your knowledge

  Several aspects of SGI's default IRIX configuration were chosen for
  convenience, not security. Unless your machine is not networked, you
  may be more concerned about security than SGI assumed.  Note that
  these items have been discussed on Usenet many times, and Usenet
  chatter is not a good way to change SGI policy. If they bother you,
  complain to your sales rep and then fix them yourself as follows.

  Under any version of IRIX,

  - Several accounts come without passwords, including (but not limited
    to) guest, 4Dgifts, demos, tutor, tour and particularly lp. Examine
    /etc/passwd and lock all unnecessarily open accounts.  Note that 1)
    parts of IRIX (e.g. 'inst') use the open guest account by default,
    and 2) remote 'lp' clients need access to the lp account to print,
    so you'll need to make other arrangements. Completists may wish to
    read CERT advisory CA-95:15, at, and
    SGI advisory 19951002-01-I, at

  - 'xdm' does 'xhost +' by default when you log in. This allows anyone
    to open windows on your display and even to record what you type at
    your keyboard. Close this hole by removing the 'xhost +' from
    /usr/lib/X11/xdm/Xsession, /usr/lib/X11/xdm/Xsession-remote and (in
    IRIX 5.x) /usr/lib/X11/xdm/Xsession.dt. In IRIX 5.2 and later you
    can use X authorization to control access to remote displays; see
    below. In IRIX 5.1.x and earlier X authorization doesn't work, so
    you'll need to use 'xhost' judiciously to get to remote displays:
    say 'xhost +localhost' to run DGL programs and 'xhost +otherhost' to
    display remote X programs.

  - At least some of the possible default values of the PATH
    environment variable begin with the current directory. (The system
    interprets either a period or the empty string in any component of
    PATH as the current directory. PATH is colon-separated, so if it
    begins with a colon the first component is the empty string.) This
    exposes you to Trojan horse programs. Set PATH to a safe value
    (remove the current directory, or at least move it to the end) in
    /etc/cshrc and/or /etc/profile for regular users and /.login for

  - By default, /etc/config/ypbind.options contains the -ypsetme
    option. This allows someone who can fake your IP address to change
    your YP binding. Remove the -ypsetme option to close the hole and
    add the -s option for a little extra protection. Comment out the
    invocations of 'ypset' in /var/yp/make.script and /var/yp/ypmake to
    avoid error messages.  If your site runs ypbind with the -v
    (verbose) option, you may also want to add 'YPSET=true' to
    /etc/config/ypmaster.options and comment out the 'ypset' line in
    /var/yp/ypmake. See the ypbind(1) and ypset(1) manpages for more.

  - If you use SLIP (see slip(1M)), be sure that SLIP accounts' home
    directories are not world-writable. SLIP accounts are uid 0, so
    it's bad if just anyone can mess with their .forward files and the
    like.  /tmp, which is recommended in the "IRIX Advanced Site and
    Server Administration Guide", is necessarily world-writable and a
    bad choice.  You may want to make an empty, root-owned, mode 755
    directory to the effect of /usr/slip and use that. Any number of
    SLIP accounts can use a single home directory without conflict.

  - Add '-a' to the rlogind and rshd lines in /etc/inetd.conf to require
    remote hostnames and addresses to match.  You *might* want to
    disallow .rhosts files by adding the '-l' flag as well, but this
    removes real functionality and should not be done without reason.
    See the rlogind(1M) and rshd(1M) manpages.  Note that rlogind's '-l'
    flag does not work in IRIX 5.2. It does work in IRIX 5.3.

  - The default root crontab in current IRIXes
    (/var/spool/cron/crontabs/root) creates the SYSLOG and cron log with
    group and world read permission. Change the '033' on lines 25 and 27
    to '077' to prevent non-superusers from reading these files.

  - By default, xdm looks for X terminal login requests on port
    177. This is no different (for security purposes) than allowing
    rlogin or telnet connections, but it might be undesirable in some
    environments. Edit /var/X11/xdm/Xaccess to restrict this access,
    e.g. by placing a `!' in front of each of the two lines which begin
    with an asterisk to prevent all XDMCP requests.

  - /etc/init.d/rmtmpfiles resets the permissions on /tmp and /var/tmp
    at every bootup. By default, permissions are set to 1777; the '1'
    means sticky, so one user can't remove another's temporary files. If
    one does 'chkconfig nostickytmp on', permissions are set to 777 and
    any user can remove another's temporary files. Don't do this: it
    allows a variety of attacks involving race conditions in setuid
    programs. A related class of attacks is described in,
    but note that Sun's tmpfs is not an essential component of the hole.

  - Non-root users can give away files. This can be used to defeat
    accounting and quotas. Set the 'restricted_chown' kernel variable to
    1 to allow only root to give away files. This may break some
    programs which depend on unrestricted chown, e.g. /bin/mail (when
    delivering to an NFS volume without root access) as discussed in the
    admin FAQ. (Thanks to Jonathan Rozes <> for this and
    the next item.)

  - NFS connections to unprivileged ports are accepted by default. Set
    the 'nfs_portmon' kernel variable to 1 to reject NFS connections
    to unprivileged ports.

  - /etc/inetd.conf enables some unnecessary services. The 'echo'
    and 'chargen' services can allow a denial-of-service attack, as
    described, for example, in CERT advisory CA-96.01, at
    To disable those particular services, comment out the lines which
    begin with their names in /etc/inetd.conf and 'killall -HUP inetd'.
    You may want to disable other unused UDP-based services as well.

  - Many devices have permissions which might allow a user to monitor
    another user via audio or video input, including


    Bill Paul <>'s solution is to add the
    following to /usr/lib/X11/xdm/Xstartup

    chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
    chown $USER /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb

    and the following to /usr/lib/X11/xdm/Xreset

    chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
    chown root /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb

    (Simon ? <> pointed out that the chmod should
    precede the chown to avoid a race condition.)

  - Read the rest of the entries in this section and make the changes
    they describe if appropriate.

  Under IRIX 5.x or later only,

  - Turn on shadow passwords, which are not used by default. Run
    'pwconv' to move your passwords to /etc/shadow, where only root can
    read them. Note that you'll have to update /etc/shadow by hand for
    NIS users. See the pwconv(1M) and shadow(4) manpages.

  - Limit the hosts from which portmap(1M) and rpcbind(1M) will accept
    RPC requests by using the -a option in /etc/config/portmap.options.
    For example, if your machine is and your subnet is you can reject RPC requests from outside your subnet by
    putting '-a' in that file. Despite the
    file's name and the absence of any options in the rpcbind manpage,
    this appears to work with rpcbind as well as portmap. Note also the
    related putative bug under "security-related bugs" below.

  This list is guaranteed to be incomplete. Keep your eyes open.
  Similar lists are in SGI's security advisory 19950401-01-I, which is
  at, and a post by Dave
  Olson <>, a copy of which is at

User Contributions:

Comment about this article, ask questions, or add new information about this topic:


Top Document: SGI security Frequently Asked Questions (FAQ)
Previous Document: -2- How can I check my system for security problems?
Next Document: -4- How can I log more information about logins?

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer: (The SGI FAQ group)

Last Update March 27 2014 @ 02:12 PM