home *** CD-ROM | disk | FTP | other *** search
Text File | 2001-07-06 | 48.7 KB | 1,005 lines |
- Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!micro-heart-of-gold.mit.edu!nntp.club.cc.cmu.edu!usenet01.sei.cmu.edu!hammer.uoregon.edu!enews.sgi.com!news.tamu.edu!sgi-faq
- From: sgi-faq@viz.tamu.edu (The SGI FAQ group)
- Newsgroups: comp.sys.sgi.misc,comp.answers,news.answers
- Subject: SGI security Frequently Asked Questions (FAQ)
- Supersedes: <security_993016817@viz.tamu.edu>
- Followup-To: comp.sys.sgi.misc
- Date: 6 Jul 2001 05:59:50 GMT
- Organization: Visualization Lab, Texas A&M University
- Lines: 986
- Approved: news-answers-request@mit.edu
- Expires: 3 Aug 2001 06:00:15 GMT
- Message-ID: <security_994399215@viz.tamu.edu>
- Reply-To: sgi-faq@viz.tamu.edu (The SGI FAQ group)
- NNTP-Posting-Host: viz.tamu.edu
- NNTP-Posting-Date: 6 Jul 2001 05:59:50 GMT
- Originator: sgi-faq@viz.tamu.edu
- Xref: senator-bedfellow.mit.edu comp.sys.sgi.misc:57362 comp.answers:46107 news.answers:210659
-
- Archive-name: sgi/faq/security
- Last-modified: Sat Jan 6 1:00:03 CST 2001
- Posting-Frequency: Twice monthly
- URL: http://www-viz.tamu.edu/~sgi-faq/
-
- SGI security Frequently Asked Questions (FAQ)
-
- This is one of the Silicon Graphics FAQ series, which consists of:
-
- SGI admin FAQ - IRIX system administration
- SGI apps FAQ - Applications and miscellaneous programming
- SGI audio FAQ - Audio applications and programming
- SGI diffs FAQ - Changes to the other FAQs since the last posting
- SGI graphics FAQ - Graphics and user environment customization
- SGI hardware FAQ - Hardware
- SGI impressario FAQ - IRIS Impressario
- SGI inventor FAQ - IRIS Inventor
- SGI misc FAQ - Introduction & miscellaneous information
- SGI movie FAQ - Movies
- SGI performer FAQ - IRIS Performer
- SGI pointer FAQ - Pointer to the other FAQs
- SGI security FAQ - IRIX security
-
- Read the misc FAQ for information about the FAQs themselves. Each FAQ is
- posted to comp.sys.sgi.misc and to the news.answers and comp.answers
- newsgroups (whose purpose is to store FAQs) twice per month. If you
- can't find one of the FAQs with your news program, you can get it from
-
- ftp://viz.tamu.edu/pub/sgi/faq/
- ftp://rtfm.mit.edu/pub/usenet/news.answers/sgi/faq/
-
- (rtfm.mit.edu is home to many other FAQs and informational documents,
- and is a good place to look if you can't find an answer here.) The FAQs
- are on the World Wide Web at
-
- http://www-viz.tamu.edu/~sgi-faq/
-
- If you can't use FTP or WWW, send mail to mail-server@rtfm.mit.edu with
- the word 'help' on a line by itself in the text, and it will send you a
- document describing how to get files from rtfm.mit.edu by mail. Send the
- command 'send usenet/news.answers/sgi/faq/misc' to get the SGI misc FAQ,
- and similarly for the other FAQs. Send the command 'send
- usenet/news.answers/internet-services/access-via-email' to get the
- "Accessing the Internet by E-Mail FAQ".
-
- You may distribute the SGI FAQs freely and we encourage you to do so.
- However, you must keep them intact, including headers and this notice,
- and you must not charge for or profit from them. Contact us for other
- arrangements. We can't be responsible for copies of the SGI FAQs at
- sites which we do not control, and copies published on paper or CD-ROM
- are certain to be out of date. The contents are accurate as far as we
- know, but the usual disclaimers apply. Send additions and changes to
- sgi-faq@viz.tamu.edu.
-
- Topics covered in this FAQ:
- ---------------------------
- -1- Where can I learn about IRIX and Unix security?
- -2- How can I check my system for security problems?
- -3- How can I configure IRIX to be more secure?
- -4- How can I log more information about logins?
- -5- How can I make an anonymous or restricted FTP account?
- -6- How can I get X authorization to work?
- -7- What security-related bugs does IRIX have?
- -8- I think I've found a security hole in IRIX; whom should I notify?
- -9- How can I get around the root and/or PROM passwords?
- -10- What firewalls are available on SGI/IRIX platforms?
-
- ----------------------------------------------------------------------
-
- Subject: -1- Where can I learn about IRIX and Unix security?
- Date: Thu Dec 7 17:14:28 CST 2000
-
- IRIX: Look in ftp://sgigate.sgi.com/Security/ and at
- http://www.sgi.com/support/security/index.html for SGI security
- advisories and patches. SGI also runs a mailing list called
- "wiretap" for dissemination of IRIX security advisories from SGI;
- its subscription address is <wiretap-request@sgi.com>. An article in
- the Jul/Aug 1994 Pipeline discusses general Unix security with some
- IRIX-specific aspects.
-
- Unix in general: Look in ftp://ftp.cert.org/,
- ftp://ciac.llnl.gov/pub/ciac/ and http://www.8lgm.org/ for CERT, CIAC
- and 8lgm material (respectively) and general security information and
- tools. If you have a lot of spare time, consider the
- comp.security.unix newsgroup and/or the bugtraq mailing list
- (listproc@netspace.org, archived at http://www.securityfocus.com/)
-
- ------------------------------
-
- Subject: -2- How can I check my system for security problems?
- Date: 04 May 1996 00:00:01 EST
-
- Get Nate Sammons <nate@vis.colostate.edu>' 'rscan' (formerly
- 'securscan') from ftp://ftp.vis.colostate.edu/pub/rscan/ (and see its
- documentation etc. at http://www.vis.colostate.edu/rscan/). It checks
- for many bugs and problems, both specific to IRIX and generic to Unix.
- Unfortunately, it has not been updated since April 1995 and will not
- detect most holes discovered since then. You might also want to try a
- generic Unix security-checking tool such as COPS, tiger or SATAN
- and/or a password checker such as Crack. SGI's security page
- referenced above gives their locations.
-
- ------------------------------
-
- Subject: -3- How can I configure IRIX to be more secure?
- Date: 30 Mar 1996 00:00:01 EST
-
- 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
- ftp://info.cert.org/pub/cert_advisories/CA-95%3A15.SGI.lp.vul, and
- SGI advisory 19951002-01-I, at
- ftp://sgigate.sgi.com/Security/19951002-01-I.
-
- - '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
- root.
-
- - 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
- ftp://ciac.llnl.gov/pub/ciac/bulletin/f-27.permissions-on-tmp.asc,
- 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 <jrozes@tufts.edu> 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
- ftp://ftp.cert.org/pub/cert_advisories/CA-96.01.UDP_service_denial.
- 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
-
- /dev/audio
- /dev/dmrb
- /dev/hdsp/*
- /dev/vid
- /dev/video
-
- Bill Paul <wpaul@ctr.columbia.edu>'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 ? <simon@instrumatic.ch> 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 www.xxx.yyy.zzz and your subnet is
- www.xxx.yyy you can reject RPC requests from outside your subnet by
- putting '-a 255.255.255.0 www.xxx.yyy.0' 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 ftp://sgigate.sgi.com/Security/19950401-01-I, and a post by Dave
- Olson <olson@sgi.com>, a copy of which is at
- ftp://viz.tamu.edu/pub/sgi/software/security/olson-security.
-
- ------------------------------
-
- Subject: -4- How can I log more information about logins?
- Date: 27 May 1996 00:00:01 EST
-
- - 'last', 'who', etc. get remote login information from
- /var/adm/utmpx and /var/adm/wtmp. That information is only logged
- into these files if they already exist. To create them, do
- 'touch /var/adm/utmpx /var/adm/wtmpx'. The analogous files under
- IRIX 4.0.x are /etc/xutmp and /etc/xwtmp.
-
- - If you're running IRIX 5.3, install patch 420 to fix a bug which
- causes xterm(1) to log logins incorrectly.
-
- - As described in the login(1) manpage, you can add the line
- 'syslog=all' to /etc/config/login.options (IRIX 4.0.x) or change the
- line 'SYSLOG=FAIL' in /etc/default/login to 'SYSLOG=ALL' (IRIX 5.x)
- to log all login attempts, not just successful ones, in
- /var/adm/SYSLOG. Under IRIX 5.x only, the same change in
- /etc/default/su has the same effect on 'su' attempts.
-
- - 'ftpd', 'rshd', 'tftpd' and 'fingerd' all have options ('-l' or
- '-L') which cause them to log all accesses. See their manpages.
- 'ftpd' also has '-ll' and '-lll' options (undocumented before IRIX
- 5.x) which log individual file transfers and the sizes of those
- files respectively. Add the options to the last fields (not the
- second-to-last) of the appropriate lines of /etc/inetd.conf, then do
- 'killall -HUP inetd' or reboot.
-
- - Consider using Wietse Venema's tcp_wrappers, at
- ftp://ftp.win.tue.nl/pub/security/. This allows you not only to log
- most types of connections, but to restrict connections from
- particular hosts and prevent some forms of address spoofing.
- README.IRIX in current versions of tcp_wrappers describes a number
- of ways in which it does not work well with IRIX, some of them
- serious. tcp_wrappers is still useful, but read README.IRIX
- carefully and test your configuration to be sure it's working.
-
- ------------------------------
-
- Subject: -5- How can I make an anonymous or restricted FTP account?
- Date: 13 Aug 1995 00:00:01 EST
-
- Read the ftpd(1M) manpage and/or the article in the March/April 1994
- Pipeline. However, both discussions have a serious error: the ftp
- account's home directory (/usr/people/ftp) should be owned and
- writable only by root, NOT ftp. You might also want to make the 'pub'
- directory "sticky" with 'chmod +t' (like /tmp and /var/tmp) so that
- one user can't delete another's files. Two scripts which set up a
- secure or restricted anonymous FTP account are at
- ftp://viz.tamu.edu/pub/sgi/software/ftp/.
-
- ------------------------------
-
- Subject: -6- How can I get X authorization to work?
- Date: 24 Feb 1996 00:00:01 EST
-
- Under IRIX 5.1.x or earlier, don't try. The MIT-MAGIC-COOKIE-1
- protocol did not work, and DGL programs did not understand X
- authorization.
-
- Under IRIX 5.2, heed the wise words of Mark Kilgard of SGI's
- X Window Systems group <mjk@hoot.asd.sgi.com>:
-
- The basic mechanism for the MIT-MAGIC-COOKIE-1 authorization protocol
- is implemented by the X server, Xlib, and xdm, and does work in IRIX
- 5.x. MIT-MAGIC-COOKIE-1 is the only supported protocol.
-
- Two caveats before I describe how to enable X authorization:
-
- 1) Old remote IRIS GL programs probably will not be able to connect to
- the X server when X authorization is enabled. (More on this below.)
-
- 2) Due to a problem with how the local hostname is handled, to use X
- authorization in the IRIX 5.x releases, you will need to make sure
- your /etc/sys_id file has a simple hostname, ie. hoot instead of a
- fully resolved hostname like hoot.asd.sgi.com This problem has
- already been fixed for the next general release of IRIX.
-
- TO ENABLE X AUTHORIZATION, do the following to your IRIX 5.2 system:
-
- 1) Edit /var/X11/xdm/xdm-config as root and change the line
- saying
-
- DisplayManager*authorize: off
-
- to say
-
- DisplayManager*authorize: on
-
- 2) Edit /var/X11/xdm/Xsession, /var/X11/xdm/Xsession-remote, and
- /var/X11/xdm/Xsession.dt as root and change the line saying
-
- /usr/bin/X11/xhost +
-
- to say
-
- #/usr/bin/X11/xhost +
-
- This disables the "xhost +" by commenting out the command.
-
- 3) Make sure your /etc/sys_id file has no periods in it. For
- example, change as root:
-
- hoot.asd.sgi.com
-
- to say
-
- hoot
-
- 4) Reboot the machine OR restart a new xdm and X server. This
- can be done as root with the following command:
-
- (/usr/gfx/stopgfx; killall xdm; /usr/gfx/startgfx) &
-
- 5) Log in. X authorization should be enabled.
-
- If you want to disable X authorization and return to the default
- system state where X clients can connect to the X server from any
- machine, reverse the changes in steps 1 and 2 and repeat step 4.
-
- If you want more information on X authorization, see the manpages for
- xdm(1), Xserver(1), Xsgi(1), Xsecurity(1), xauth(1) and xhost(1).
-
- X AUTHORIZATION AND REMOTE IRIS GL PROGRAMS: One of the major reaons
- for Silicon Graphics shipping its window system so that an X client
- from any machine could connect to the X server was because IRIS GL
- programs running remote using the DGL (distributed GL) protocol didn't
- interoperate with the X authorization mechanism; the dgld daemon that
- would run on the machine with graphics hardware had no way to get the
- correct X authorization information to connect to the X server.
-
- This has been fixed for IRIX 5.2, but the fix only applies to IRIX 5
- binaries running remotely on an IRIX 5.2 system connecting to an IRIX
- 5.2 X server. In particular, remotely run IRIX 4 IRIS GL binaries
- will continue to not interoperate with an IRIX 5.2 X server (or a
- pre-IRIX 5.2 X server). If you recompile your old IRIS GL binaries
- on IRIX 5.2, they then will work remotely connecting to IRIX 5.2 X
- servers running X authorization.
-
- The bottom line is that if you want an IRIS GL program to run
- remotely on an X server using X authorization, you need to make sure
- the program is an IRIX 5 binary running on an IRIX 5.2 machine and
- the machine with the X server is also an IRIX 5.2 machine.
-
- To avoid a possible misconception: IRIS GL programs RUNNING LOCALLY
- (ie, not using DGL) WILL WORK FINE on an IRIX 5.2 system no matter if
- they are IRIX 4 or IRIX 5 binaries. The problem with X authorization
- is only for REMOTE IRIS GL programs.
-
- Also note that for X authorization to work for remote hosts, the
- remote program must have access to the correct X authorization magic
- cookie (normally read from ~/.Xauthority). If you don't have a
- shared NFS mounted home directory, you'll probably need to use the
- xauth command to transfer the X authorization magic cookie to the
- remote ~/.Xauthority file.
-
- THE FUTURE: Hopefully in the next general release of IRIX, a
- mechanism to enable and disable X authorization using a chkconfig
- option will be supported. The problem with /etc/sys_id not having
- periods will definitely be fixed in the next general release of
- IRIX. The problem with pre-IRIX 5.2 X servers and binaries not
- interoperating with X authorization will likely not be fixed. Fixing
- the problem required a DGL protocol extension which both the IRIS GL
- program and dgld must know about; this can't be fixed in already
- shipped software.
-
- Under IRIX 5.3, do what you did for IRIX 5.2. There is no chkconfig
- option for X authorization. The problem with periods in hostnames is
- still present in 5.3 as such, but is fixed by patch 518. There is a
- bug in NFS3 which truncates ~/.Xauthority files which is fixed by
- patch 216. See also the descriptions of the shared memory hole and the
- putative X authorization weaknesses below under "security-related
- bugs".
-
- ------------------------------
-
- Subject: -7- What security-related bugs does IRIX have?
- Date: 4 Jun 1997 00:00:01 EST
-
- (Thanks to Yuri Volobuev <volobuev@t1.chem.umn.edu> for updating
- several questions in this question.)
-
- Some general comments before we start:
-
- - IRIX is too complex for us to guarantee that this list is complete.
- We only discuss problems we know about. We don't discuss insecurely
- designed systems (like YP) or ways in which you might misconfigure
- your system, only bugs. We don't discuss third-party software,
- free or not.
-
- - Prudence and space permit us to describe only how to close holes,
- not to exploit them. Try comp.security.unix.
-
- - Some of the fixes involve installing a new version of a setuid
- binary. Be sure that you 1) make it executable, setuid and owned
- by the correct user and group (or it won't work), and 2) remove the
- old version so bad guys can't use it!
-
- Now for the holes themselves:
-
- - ftp://ftp.cert.org/pub/cert_advisories/CA-92:08.SGI.lp.vulnerability
- describes problems with the permissions of 'lp'-related parts of
- IRIX which allow anyone who can log in as lp to get root access.
- They are fixed in IRIX 4.0.5. Briefly, the fix is
-
- su root
- cd /usr/lib
- chmod a-s,go-w lpshut lpmove accept reject lpadmin
- chmod go-ws lpsched vadmin/serial_ports vadmin/users vadmin/disks
- cd /usr/bin
- chmod a-s,go-w disable enable
- chmod go-ws cancel lp lpstat
-
- - ftp://ftp.cert.org/pub/cert_advisories/CA-93:17.xterm.logging.vulnerability
- describes a hole in /usr/bin/X11/xterm which allows any user root
- access. It is fixed in IRIX 5.x. A fixed version for 4.x is at
- ftp://ftp.sgi.com/sgi/IRIX4.0/xterm/. The 'fix', incidentally, is
- that logging is completely disabled.
-
- - /usr/bin/under is an unused (!) part of 'rexd'. It is setuid root
- and may allow root access, so 'chmod -s' it just in case. Note that
- SGI ships IRIX with 'rexd' turned off because 'rexd' is itself a
- security problem. It is not shipped in IRIX 5.x.
-
- - ftp://ciac.llnl.gov/pub/ciac/bulletin/f-fy95/f-01.ciac-SGI-IRIX-serial-ports
- describes a race condition in IRIX 4.0.x's
- /usr/lib/vadmin/serial_ports which allows any user to become root
- in IRIX 4.0.x. 'chmod 700' it to close the hole; it will still work
- fine.
-
- /usr/lib/vadmin/serial_ports is part of IRIX 4.0.x and should not
- exist on IRIX 5.x systems, but some users have reported problems
- with upgrading from 4.0.x to 5.x which leave old binaries behind.
- If the file exists on your 5.x system, remove it. (5.x's
- equivalent, /usr/Cadmin/bin/cports, does not have the problem.)
-
- - /usr/bsd/rdist has several holes which allow any user root access in
- all versions of IRIX before 5.3, including the 4.0.5 and 5.x
- binaries on ftp.sgi.com.
-
- Under IRIX 5.2, you can install patch 130 to close all known
- holes. Under IRIX 4.0.x, you must close the hole with 'chmod -s'.
- rdist will then work only when used by root. If your non-root users
- need 'rdist', there is a free version, which does not need to be
- setuid root and is thus free of all known holes, in
- ftp://usc.edu/pub/rdist/. Make sure you get version 6.1 beta 3 or
- later. IRIX 5.3's rdist is derived from this version and is thus
- equally safe; presumably ordist is the IRIX 5.2-patch 130 rdist and
- is also safe.
-
- As for advisories, CERT advisory CA-91:20, at
- ftp://ftp.cert.org/pub/cert_advisories/CA-91:20.rdist.vulnerability
- is badly out of date, and
- http://www.8lgm.org/advisories/[8lgm]-Advisory-1.UNIX.rdist.23-Apr-1991
- and
- http://www.8lgm.org/advisories/[8lgm]-Advisory-26.UNIX.rdist.20-3-1996.html
- may not describe all of the known holes.
-
- - The 'lpr' subsystem in every version of IRIX before 5.3 has several
- holes which allow a non-root user to become root. Note that 'lp' is
- SGI's usual printing system; you only need 'lpr' if you need to deal
- with remote printers. If you don't need 'lpr', make sure it isn't
- installed. (It lives in the eoe2.sw.lpr subsystem.) If you do need
- 'lpr', there are fixed versions at
-
- ftp://ftp.sgi.com/sgi/IRIX4.0/lpr/lpr.latest.Z
- ftp://ftp.sgi.com/sgi/IRIX5.0/lpr/lpr.latest.Z
-
- The versions dated 29 and 26 April, respectively, work with NIS
- (YP). The IRIX 5.x version is also available as patch 131.
-
- - /usr/sbin/cdinstmgr is setuid root in IRIX 4.0.5[A-F] and
- /etc/init.d/audio is setuid root in IRIX 5.2. They are scripts;
- setuid scripts are a well-known Unix security problem. IRIX ignores
- the setuid bit by default, but 'chmod -s' the scripts just in case.
-
- - ftp://sgigate.sgi.com/Security/19950209-01-P describes a bug in
- colorview in IRIX 5.x before 5.3, which allows anyone to use it to
- read any file regardless of permissions, and gives a fix.
-
- - /usr/bin/newgrp is group-writable in IRIX 5.2. It doesn't need to
- be, and it might be a problem depending on your use of group sys
- and/or the presence of the 'sadc' bug (described elsewhere in this
- list) on your system. 'chmod g-w' it.
-
- - /usr/sbin/printers has a bug in IRIX 5.2 (and possibly earlier 5.x
- versions) which allows any user to become root. Apply patch 5. You
- might want to 'chmod -s' it while you're waiting.
-
- - /usr/sbin/sgihelp has a bug in IRIX 5.2 (and possibly earlier 5.x
- versions) which allows any user to become root. This is so bad that
- the patch (#65, along with the prerequisite patch 34) is FTPable
- from ftp://ftp.sgi.com/security/, and SGI is preparing a CD
- containing only that patch. Call the TAC if you can't FTP. You
- should 'chmod -x /usr/sbin/sgihelp' while you're waiting.
-
- - The inst which comes with patch 34 (for IRIX 5.2), which is required
- for installation of all other patches (even those with lower
- numbers) saves old versions of binaries in /var/inst/patchbase. It
- does not remove execution or setuid permissions! 'chmod 700' that
- directory so evil users can't get to the old binaries. The bug is
- fixed in patch 82 for IRIX 5.2 and in IRIX 5.3.
-
- - http://www.8lgm.org/advisories/[8lgm]-Advisory-11.UNIX.sadc.07-Jan-1992
- describes a hole in the System V system activity reporting program
- /usr/lib/sa/sadc which allows any user to write files with the
- permissions of that program. This bug is present in all versions of
- IRIX through 5.3, but since /usr/lib/sa/sadc is only setgid sys it
- can only be used to change groups sys-writable files or write files
- in group sys-writable directories. If you don't use the system
- activity reporter you might want to 'chmod -s /usr/lib/sa/sadc' just
- to be safe. Because this hole isn't serious it isn't scheduled to be
- closed, but write permission for group sys has been removed from
- most directories where it wasn't necessary in IRIX 5.3, and a few
- more (/dev/*dsk) will be fixed in a later release.
-
- - /usr/etc/mount_dos, IRIX's DOS-filesystem floppy mounter, has a
- serious bug in IRIX 5.2 (and probably earlier releases of 5.x as
- well) which allows anyone with an account on and physical access to
- a machine with a floppy drive root access. This bug can be fixed
- with patch 167 and is reportedly fixed in IRIX 5.3. Perhaps the
- easiest interim "fix" (which essentially disables all removable
- media drives) is to disable mediad: "mediad -k" kills the current
- instance of mediad, and "chkconfig mediad off" prevents mediad from
- starting during the next reboot.
-
- - ftp://ftp.cert.org/pub/cert_advisories/CA-95%3A17.rpc.ypupdated.vul
- describes a security hole which is present in /usr/etc/rpc.ypupdated
- in all versions of IRIX. It is completely unnecessary in most
- networks; the only instance that we could think of that might
- require this daemon would be NIS networks that include Sun diskless
- clients. You should probably comment it out of /etc/inetd.conf, or
- just not install the nfs.sw.nis subsystem, of which it is a part. It
- is commented out by default in IRIX 5.3.
-
- - ftp://sgigate.sgi.com/Security/19950301-01-P373
- describes a bug in /usr/lib/desktop/permissions in IRIX 5.2, 6.0 and
- 6.0.1 which allows any user to change the permissions of any file to
- anything. (Click on "Apply" twice fast, then click "Cancel" to
- dismiss the root password window.) It is fixed in patch 373 for IRIX
- 5.2, 6.0 and 6.0.1 and in IRIX 5.3. Until you patch or upgrade,
- 'chmod -s' it to close the hole.
-
- - sendmail is a complex program in which new security holes are
- discovered almost daily. Some of these holes enable unprivileged
- users (and in one case even *remote* users!) to gain root access.
- The safest course of action seems to be to use the most recent
- sendmail possible.
-
- Recent sendmail patches also fix a bug present in every IRIX
- sendmail before 5.3: /usr/bsd/newaliases (which is just a symlink to
- /usr/lib/sendmail) creates /etc/aliases.{dir,pag} with mode 666. Any
- user can thus add aliases which can run programs or steal mail.
- Close the hole with 'chmod go-w /etc/aliases.dir /etc/aliases.pag'.
- sendmail doesn't change those files' permissions once they exist, so
- a) you should check them even if you've installed a sendmail in
- which the problem is fixed and b) once they exist and have proper
- permissions, you're OK.
-
- - /usr/etc/arp has a hole in IRIX 5.2 and earlier which allows any
- user to read files with 'arp's permissions, i.e. group sys. Close
- the hole with 'chmod -s'. This prevents non-root users from using
- 'arp' at all, but they don't generally need it. The hole is closed
- in IRIX 5.3.
-
- - SoftWindows 1.25 (which is distributed by SGI in Desktop Support
- Environment 1.0 and HotMix 11) includes an installation script which
- executes Netscape as root. This can be used to gain root access,
- etc. Patch 905 (if your Softwindows is installed as the
- "SoftWindows" subsystem) or 908 (if it's in the "swin" subsystem)
- fixes the script.
-
- - ftp://ftp.cert.org/pub/cert_advisories/CA-95:14.Telnetd_Environment_Vulnerability
- describes a vulnerability in telnetd which is present in IRIX before
- 6.2. A remote user can use telnet/telnetd to pass environment
- variables to login which cause login to use an arbitrary shared
- library. If the same user can place a shared library on the system
- running telnetd (e.g. by depositing it in an incoming FTP
- directory), that user can gain root permissions. There is a related
- hole in login(1): it allows one to set LD_ envariables from the
- command line, and, if they are already present in its environment,
- passes them to programs which it invokes. Patches 1010, 1020 and
- 1143 for various versions of IRIX close the holes, as does IRIX 6.2.
-
- - ftp://sgigate.sgi.com/Security/19960101-01-PX describes a hole in
- the objectserver which allows a local or remote user to become
- root. Patch 1052 to IRIX 5.2, 6.0 and 6.0.1, patch 1048 to IRIX 5.3
- and patch 1090 to IRIX 6.1 close the hole. Note that patch 1048
- (and perhaps its cousins) comes with a mediad which doesn't
- properly handle audio CDs, and that its successor, patch 1096
- (successors to 1052 and 1090 are not yet available) breaks
- cformat(1M); see the admin FAQ.
-
- - ftp://sgigate.sgi.com/Security/19960102-01-P
- describes a hole in /usr/pkg/bin/pkgadjust (part of the SVR4 pkg
- system, in eoe2.sw.oampkg, not installed by default) which allows
- local users to overwrite files and execute arbitrary programs as
- root. To close the hole, either remove eoe2.sw.oampkg or 'chmod -s
- /usr/pkg/bin/pkgadjust'. If you do leave eoe2.sw.oampkg installed,
- note that /usr/pkg/bin/abspath is setuid root as well. This is not
- yet known to be a security problem, but is certainly not necessary,
- and the careful admin will want to 'chmod -s' it as well. Since
- neither program needs to be setuid, no patch is necessary. Future
- releases of IRIX will not install them setuid.
-
- - ftp://sgigate.sgi.com/Security/19960301-01-P and
- ftp://ftp.cert.org/pub/cert_advisories/CA-96.09.rpc.statd describe a
- hole in rpc.statd (see statd(1M)), present in all IRIXes before 6.2,
- which allows a remote user to mount denial-of-service attacks or
- create or remove files as root. Patch 1226 (IRIX 5.2), 1128 (6.0 and
- 6.0.1) and 1391 (5.3) close the hole. There is no patch for IRIX
- 6.1. The hole is fixed in IRIX 6.2.
-
- - The xdm(1) manpage(!) describes a bug in IRIX 5.x (at least) which
- allows a user to connect to a local display even when X
- authorization should prevent one from doing so. (Fortunately, this
- doesn't work for remote displays.) Close the hole with patch 1075,
- or just turn off shared memory transport by adding the option
- '-shmnumclients 0' to the X command in /usr/lib/X11/xdm/Xservers.
- See also the lengthy discussion of X authorization above and the
- description of the putative X authorization weaknesses below.
-
- - LicenseManager 2.0 (a prerequisite for some of the free software
- on Silicon Surf) a) allows any user to manipulate licenses and, b)
- when one adds a new license, may delete old, unrelated licenses. The
- problem is fixed in LM 2.0.1. Also, LicenseManager 1.x through 3.0
- have bugs in them which can allow any user to become root. 'chmod
- -s /usr/etc/LicenseManager' will close them; however, this will
- preclude any user other than root from using LicenseManager to
- manipulate licenses.
-
- - ftp://info.cert.org/pub/cert_advisories/CA-96.08.pcnfsd describes a
- bug which allows remote users to run commands as root on a pcnfsd
- server. The bug is present in the version of pcnfsd which SGI
- provides for IRIX 5.3, but not in that for IRIX 6.2 (or other IRIX
- 6.x?). It is fixed by patch 1179 for IRIX 5.3.
-
- - /usr/bin/rmail has a bug which allows a local user to assume the
- permissions of group mail, and thus (most importantly) read anyone's
- mail. It is fixed in patch 1273 for IRIX 5.2-6.1 and 1281 for 6.2.
-
- - ftp://sgigate.sgi.com/Security/19960501-01-PX and
- ftp://sgigate.sgi.com/Security/19960801-01-PX describe holes in the
- desktop administration tools which allow users to change permissions
- on and edit files which they do not own. They are closed by patches
- 1519, 1518, 1517 and 1516 for IRIX 5.2, 5.3, 6.1 and 6.2
- respectively.
-
- - /usr/bin/X11/cdplayer and /usr/sbin/datman (also known as 'cdman')
- have security holes in them that can allow users to execute
- arbitrary programs as root. At this time, SGI has not released
- patches for these programs yet, so the way to close the hole is via
- 'chmod -s /usr/bin/X11/cdplayer /usr/sbin/datman'. This will
- unfortunately prevent non-root users from using cdman, datman, and
- cdplayer; other Motif-based CD players are available on the
- Internet which may not share cdplayer's vulnerabilities.
- These problems are described in more detail in AUSCERT advisories
- ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-96.11.SGI.cdplayer.vul
- and
- ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-96.20.SGI.datman.cdman.vul
-
- - /var/rfindd/fsdump has a security hole in it which allows users to
- overwrite arbitrary files and (in so doing) gain root access.
- 'chmod -s /var/rfindd/fsdump' will close the hole and also disable
- rfindd.
-
- - /sbin/suid_exec, a component of ksh that assists ksh in running
- setuid shell scripts, has a security hole in it that allows users
- to execute arbitrary programs as root. 'chmod -s /sbin/suid_exec'
- will close the hole and also prevent ksh from executing setuid
- shell scripts. (Execution of setuid shell scripts is off by default
- on most releases of IRIX anyway.)
-
- - /usr/Cadmin/bin/csetup, the "EZsetup" system setup manager, has a
- security hole in it that allows users to execute arbitrary programs
- as root.
-
- - ftp://sgigate.sgi.com/security/19961203-01-PX describes a vulnerability
- in /usr/lib/print/netprint, which allows any local user to become root.
- Apply following patch 1685 (for 5.3/6.1) or 2022 (for 6.2). 5.2 doesn't
- have netprint. Note, that this patch may break printing. To fix it,
- add this to the top of /etc/init.d/lp
-
- TMPDIR=/var/tmp
- export TMPDIR
- HOME=/var/spool/lp
- export HOME
- LOGNAME=lp
- export LOGNAME
-
- then run "/etc/init.d/lp stop ; /etc/init.d/lp start"
-
-
- These bugs have not yet been fixed:
-
- - /usr/bin/lp has several bugs that allow any local user to gain lp
- privileges. If you don't need its functionality, consider removing the
- suid bit from lp. If you do need it, you can "wrap" the lp binary
- with a wrapper that cleans up critical environment variables
- (e.g. PATH), checks the command line for shell metacharacters and
- length limits.
-
- - The default root crontab contains a call to /usr/etc/fsr. By default,
- under certain conditions it can be used to obtain root privileges.
- Edit root's crontab and add "-f /var/adm/.fsrlast" option to the
- fsr command line.
-
- - /usr/etc/cvpcsd is part of the CaseVision WorkShop package. It's
- invoked by inetd with root priviledges. It has a vulnerability that
- allows any root priviledges. It has a vulnerability that allows any
- local user to overwrite any file on the system, and, under certain
- conditions, become root.
- Check your /etc/inetd.conf for this or a similar line:
-
- sgi_pcsd/1 dgram rpc/udp wait root ?/usr/etc/cvpcsd pcsd
- -L
-
- if it's there, consider commenting it out. (Don't forget to
- 'killall -HUP inetd' after you've commented it out.)
-
- - /usr/lib/InPerson/inpview, part of the InPerson desktop conferencing
- tool, has a vulnerability that allows any local user to become root.
- If you don't need InPerson functionality, remove the suid bit from
- inpview (with 'chmod u-s /usr/lib/InPerson/inpview'). If you do
- need it, restrict execution privileges to the trusted group of
- individuals that have access to the console.
-
- - /usr/bin/startmidi that comes with the standard IRIX 5.3 distribution
- has a vulnerability that allows any local user to become root.
- However, startmidi that comes with Desktop Special Edition 1.1 is not
- vulnerable to this problem. IRIX 6.2 doesn't seem to be vulnerable
- either. Check your machine by running "showfiles | grep startmidi".
- If your output is:
-
- f 64563 18688 dmedia_eoe.sw.midi usr/sbin/startmidi
-
- your machine is most likely not vulnerable to this problem. If you see
-
- f 46022 18608 dmedia_eoe.sw.midi usr/sbin/startmidi
-
- your system is probably vulnerable, so remove the suid bit from
- startmidi (with 'chmod u-s /usr/sbin/startmidi'). If it's
- neither of the above, remove the suid bit just to be safe. There's no
- official advisory or workaround for this problem.
-
- - /usr/lib/so_locations.old can acquire random permissions after an
- 'inst' session in IRIX 5.3, due to a linker bug. It may become both
- executable and setuid and/or setgid. It is not a script but could be
- used as one; setuid scripts are a well-known Unix security problem.
- IRIX ignores the setuid bit by default, but 'chmod -xs' it just in
- case. The linker bug should be fixed in IRIX 6.2.
-
- - /usr/Cadmin/bin/csetup, the "EZsetup" system setup manager, has a
- security hole in it that allows users to execute arbitrary programs
- as root. 'chmod -s /usr/Cadmin/bin/csetup' will close the hole
- but prevent non-root users from running csetup. This bug is present
- in IRIX 5.3 and probably in later versions as well.
-
- - xwsh recognizes escape sequences which remap keys. An evildoer
- can place escape sequences in a file or filename which, when passed
- to xwsh to be displayed, remap keys to unexpected strings or to
- xwsh internal functions. The escape sequences are not displayed and
- may not be detected by the victim.
-
- Programs which can pass these escape sequences to xwsh include
- 'cat', 'more', /bin/mail and /usr/bsd/Mail, and other programs such
- as mail and news agents which call these programs to display text.
- Programs which display filenames, such as 'ls' and 'find', can pass
- escape sequences in filenames to xwsh.
-
- Programs which do not recognize the remapping sequences, such as
- xterm and MediaMail, and programs which remove escape sequences
- from displayed text or replace them with safe characters, such as
- 'ls' with the '-b' or '-q' option, 'more' with the '-r' option, the
- 'less' pager and the Elm mailer's built-in pager, are safe.
-
- This vulnerability is inherent in the ANSI standard escape codes
- which xwsh respects; any terminal or terminal emulator which
- recognizes these sequences has this problem. Recognition of these
- escape codes ought to be optional, e.g. controlled by an X
- resource. It will be in IRIX 6.2 (although a cursory search of the
- man page xwsh(1) does not reveal how to do so). No patch is planned
- for earlier versions of IRIX.
-
- The safest workaround is to use xterm instead of xwsh. The next best
- is to run only safe programs and/or display only safe text in xwsh
- windows. If you use xwsh, alias 'ls' to 'ls -b' and 'more' to 'more
- -r'. You could alias 'cat' to 'cat -v', or (to avoid corrupting
- files when using 'cat' in pipelines) train yourself not use 'cat' to
- display files.
-
- - ftp://ftp.cert.org/pub/cert_advisories/CA-95:13.syslog.vul
- describes a problem with the syslog(3) system call in which data
- passed to syslog(3) can corrupt the stack and cause execution of
- arbitrary code. If a program will accept data from an untrusted
- (even remote) user and pass it to syslog(3) without bounds checking,
- a *very* clever user can usurp the permissions of that program.
-
- The hole will be closed in IRIX 6.2. There are no patches for
- current versions of IRIX, and none are planned, because SGI finds it
- difficult to distribute an installable patch to libc.so (where
- syslog(3) lives). However, patch 1146 prevents sendmail from passing
- dangerous data to syslog(3) in the first place, which prevents
- exploitation of the hole via sendmail only.
-
- - /usr/lib/X11/app-defaults/ISDN, the X resources file for the ISDN
- confidence test module which is part of at least some versions of
- SGI's ISDN software (details welcome), is both executable and setuid
- root. It is not a script but could be used as one; setuid scripts
- are a well-known Unix security problem. IRIX ignores the setuid bit
- by default, but 'chmod -xs' it just in case. This will be fixed in
- IRIX 6.2.
-
- - http://www.stardot.net/~hhui/SDN-advisories/SDN-2-sgi-videoframer a)
- describes a hole in the VideoFramer development software which
- allows a local user to overwrite files, and b) points out that VF
- includes many setuid scripts, which are a well-known Unix security
- problem (although not in the default IRIX configuration). Fix both
- problems with 'chmod -s /usr/video/vfr/*'.
-
- - /usr/gfx/setmon has holes (present at least in IRIX 5.3) which allow
- a local user to read files which should be readable only by root and
- to crash the machine. 'chmod -s' it. (Thanks to Hui-Hui Hu
- <hhui@stardot.net>.)
-
- - /usr/etc/uncompvm in IRIXes up to 5.3 and 6.1 is setgid sys. It
- doesn't need to be (crash dumps are readable only by root, not by
- group sys) so 'chmod -s' it. It will not be setgid sys in IRIX 6.2.
- (Thanks to Hui-Hui Hu <hhui@stardot.net>.)
-
- - par(1) will display data read by a setuid program, even if the
- program would not itself have printed that data. One can thus use
- par and a suitably leaky setuid program (known examples include
- arp(1M), setmon(1G) and uncompvm(1M)) to read files for which one
- would otherwise not have permission. This will be fixed by a
- patch to IRIX 5.3 and in IRIX 6.2.
-
- - ftp://ftp.cert.org/pub/cert_advisories/CA-96.19.expreserve describes
- a bug in expreserve which allows any user to overwrite any file on
- the system. ftp://sgigate.sgi.com/Security/19960802-01-I explains
- that since SGI's expreserve is setgid sys rather than setuid root as
- on some othere systems (yay SGI!), it can only overwrite files which
- can be written by group sys. Since there are no important files
- which can be written by group sys, no patch is planned. The bug will
- be fixed in a future release. Make sure that there are, indeed, no
- important files on your system which are writable by group sys. If
- you don't need expreserve, 'chmod -s' it.
-
- The following advisories describe holes whose presence in IRIX we
- can't confirm or deny at present:
-
- http://www.8lgm.org/advisories/[8lgm]-Advisory-12.UNIX.suid_exec.27-Jul-1991
- ftp://ftp.cert.org/pub/cert_advisories/CA-94%3A15.NFS.Vulnerabilities
- ftp://ftp.cert.org/pub/cert_bulletins/VB-95%3A08.X_Authentication_Vul
- ftp://ftp.cert.org/pub/cert_advisories/CA-96.02.bind
-
- ------------------------------
-
- Subject: -8- I think I've found a security hole in IRIX; whom should
- I notify?
- Date: 31 May 1995 00:00:01 EST
-
- First, call the TAC as for any bug. Next, send email to
- security-alert@sgi.com. You can also notify CERT <cert@cert.org>, who
- will contact the appropriate people from their contact list. They may
- take some time.
-
- ------------------------------
-
- Subject: -9- How can I get around the root and/or PROM passwords?
- Date: 20 Apr 1996 00:00:01 EST
-
- To get around the root password, start 'inst' from an IRIX CD or tape
- as you would if you wanted to install software. (See chapter 3 of the
- Software Installation Administrator's Guide.) If you've set a PROM
- password, you'll need to provide it or circumvent it first; see below.
- Say 'admin shroot' to get a root shell. You can then do any of the
- following:
-
- - use 'passwd' to change root's password
- - 'setenv TERM iris-tp' and 'vi/etc/passwd'
- - if /etc/passwd is really hosed, 'mv' the remains out of the way and
- 'echo root::0:0:root:/:/bin/sh > /etc/passwd'.
-
- Alternatively, if your machine is an NIS client you can change the uid
- of an NIS account to 0 from the server and do a 'ypmake'.
-
- If you've lost your PROM password but can still log in as root, you
- can zero the PROM password with 'nvram passwd_key ""'. If not, you'll
- have to disable the PROM password via the hardware. On a 4D/35 or
- Crimson, find the battery which maintains the nvram ("non-volatile
- RAM") and remove it. On an Indigo or Indy, find the nvram chip itself
- and remove it. On an Indigo^2, remove the jumper described in the
- owner's manual. This may be a good time to call SGI.
-
- ------------------------------
-
- Subject: -10- What firewalls are available on SGI/IRIX platforms?
- Date: 16 Mar 1996 00:00:01 EST
-
- Ping Huang <pshuang@sgi.com> writes:
-
- SGI is an OEM for Gauntlet (from Trusted Information Systems), meaning
- that SGI sells and supports Gauntlet directly. See
- http://www.tis.com/docs/Products/gauntlet.html for general Gauntlet
- product information. See your SGI sales person for specific
- information about Gauntlet for IRIX.
-
- I believe that is the only commercial firewall product currently
- available, although there are freely distributable (but unsupported
- and possibly dated) alternatives like the TIS Firewall Toolkit. If you
- want more choices, please make your desires for availability on the
- SGI/IRIX platform known to your favorite firewall vendor(s).
-
- ------------------------------
-
- End of sgi/faq/security Digest
- ******************************
- --
- The SGI FAQ group <sgi-faq@viz.tamu.edu> http://www-viz.tamu.edu/~sgi-faq/
- Finger us for info on the SGI FAQs, or look in ftp://viz.tamu.edu/pub/sgi/.
-