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 ftp://info.cert.org/pub/cert_advisories/, and SGI advisory 19951002-01-I, at ftp://sgigate.sgi.com/Security/. - '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/. 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/, 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. User Contributions: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: sgi-faq@viz.tamu.edu (The SGI FAQ group)
Last Update March 27 2014 @ 02:12 PM
|
Comment about this article, ask questions, or add new information about this topic: