University of California at Berkeley Department of Electrical Engineering & Computer Sciences Instructional & Electronics Support /usr/pub/security.help http://www-inst.eecs.berkeley.edu/usr/pub/security.help Aug 30, 1998 Security on the Instructional Systems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CONTENTS -------- Protect yourself! File permissions Passwords Unattended logins .rhosts files X Windows Security File encryption Mail encryption Network encryption "set uid" programs are not allowed in home directories "ftp", "rlogin" and "telnet" are restricted on some systems Protect yourself! ---------------- Users of the UNIX systems should be aware of these features which, if used improperly, can allow people to break into an account, read or delete files, and use the account for other malicious purposes. UNIX help sessions that cover these issues are presented each semester by the CSUA and XCF student groups (343 Soda, 311 Soda). File permissions ---------------- UNIX file permissions on a given file can be viewed with the UNIX command "ls -al ". File permissions are controlled with the commands "chmod", "chgrp" and "umask". Users are advised to be aware of the permissions on their files and directories and to read the man pages for these commands. It is strongly discouraged to have files or directories that are writable by anyone but the owner. Passwords --------- Your password is your best defense against users accessing your account from remote computers. With increasing frequency, malicious people are running "crack" programs that can guess passwords that are based on dictionary words and user information displayed by "finger" (your name, login, or etc). So you should pick a password that is not easily guessed and be careful to keep it private. The UNIX program "passwd" is used to change your password. It tries to identify passwords that are easily guessed and will not allow you to choose them. You may change your password as often as you wish. Unattended logins ----------------- If you login in at a workstation and then leave, you are leaving yourself open to attack. Others can sit there and use your account as if they were you. So don't leave your login sessions unattended. .rhosts files ------------- There are a series of UNIX commands that can bypass password security to access computer accounts. These commands include "rcp", "rlogin", "rsh" (on DECs) and "remsh" (on HPs). You can create a file called ".rhosts" in your home directory that allows access without a password from other accounts. THIS CAN BE VERY DANGEROUS and should be used with extreme care. Here is an example of a relatively safe entry in your Instructional .rhosts file: uclink.berkeley.edu mylogin This allows only you (if your login is "mylogin") to login only from "uclink" without a password. Note that if someone hacks into your Uclink account, this will allow them free access to your Instructional account as well. You should NEVER install a "+" sign in either the hostname or login fields of an .rhosts file. The "+" sign is a wild card that means "every host" or "every user". Finally, if you use an .rhosts file, permissions on your home directory and on the .rhosts file should be world-executable. This command will do that: chmod o+x ~ ~/.rhosts and the results of the "ls" command should look something like: ls -lad ~ ~/.rhosts drwxr-xr-x 25 you 1536 Jan 2 17:53 your-home-dir drwxr-x--x 37 you 2048 Jan 3 16:50 your-home-dir/.rhosts X Windows Security ------------------ In the early versions of X Windows, security limited access to a specified computer, but allowed EVERY user logged in at that computer to access the X Window server. If you logged in at a workstation and someone else logged into it over the network, that person could pop up an xterm on your screen or even run a program that read the keystrokes that you were typing. For example, if you typed "xhost +cory.eecs", ALL users on cory.eecs would have that same access as you to your X server. This security hole has been plugged with the "xauth" utility. When you first login at a workstation, a file called .Xauthority is automatically created or updated in your home directory. The "xauth" program accesses this file. .Xauthority contains a key, or "MAGIC-COOKIE", that "locks" your display. If another user tries to access your X server, the attempt will succeed only if that user has a copy of your key is his/her own .Xauthority file. If you are working on different computers that share your home directory (such as the Instructional systems), you do not need to use "xhost" or "xauth" at all. Wherever you are logged in, you will be referencing your own single .Xauthority file and the key that's in it. But if you wish to allow access to another user (or another account of your own), you will need to give your MAGIC-COOKIE key to that user so the user can add it to his/her .Xauthority file. Here's an example of one way to do that: ------------------------------------------------------------------------- Given: You are logged in at an Instructional workstation, say "ike.cs". You are also logged into another account, say "soda.csua". You type (ike% represents your prompt on ike): ike% xauth list | grep ike ike.cs:0 MIT-MAGIC-COOKIE-1 cc779d8af890dc478db0d03ea03b0ac7 ike.cs:0 XDM-AUTHORIZATION-1 bbf36d10c2a916f00002b979617dab11 The output of the xauth command appears on the screen. Then, on your other account, you would do the following: soda% xauth xauth> add ike.cs:0 MIT-MAGIC-COOKIE-1 cc779d8af890dc478db0d03ea03b0ac7 xauth> exit soda% setenv DISPLAY ike.cs:0 soda% xterm and an xterm window should pop up on the ike.cs console screen. Obviously, instead of typing in the whole MAGIC-COOKIE line, you could just use the mouse to paste it in. Here is a one-line method of doing that: ike% xauth extract - $DISPLAY | rsh pauli xauth merge - Thus requires that you can "rsh" from one account to the other; this is best enabled using Kerberos (see /usr/pub/kerberos.help). Note also that the X authorization scheme has changed between different releases of X11. If the X program you are trying to run was compiled with older X libraries, then this might not work. In that case, you will probably have to fall back on host-based access control, using a command such as: ike% xhost +soda This will let _anyone_ on Soda access your X server. Some people know how to access an X server to read all keystrokes typed there, so by allowing unknow users to have access you are taking a security risk. ------------------------------------------------------------------------- Two security notes: - When typing a MAGIC-COOKIE, do it within the interactive "xauth" program. Avoid entering it on a command line, because the text of a command line can be seen by anyone using the "ps" command. - Be sure your .Xauthority file is readable and writable only by you. In an "ls" listing, it should look like: -rw------- 1 your-login 49 May 10 15:41 .Xauthority Please read "man xauth" for more details. File encryption --------------- UNIX has (at least) a couple of commands with which you can encrypt and decrypt a file using a key (like a password) of your own choice. These commands include "encrypt", "decryypt", "bdes -k" and "bdes -d". See "man encrypt" and "man bdes" for usage. Mail encryption --------------- Mail to and from other users can be encrypted by use of the 'pgp' command. For instructions on setting this up, see 'man pgp' and http://www.pgp.com/ Network encryption ------------------ Unfortunately, any traffic transmitted over a shared network can be intercepted by other users of that network. Many accounts have been broken into in the past when their passwords were 'sniffed' while going across the network. To prevent this from happening, you can encrypt your network connections using ssh or kerberos. ssh is easier to setup and use, and also handles Xwindows traffic so you don't need to manage your .Xauthority when displaying remotely. For more information on ssh, see /usr/pub/ssh.help. For more information on kerberos, see /usr/pub/kerberos.help. "set uid" programs are not allowed in home directories ------------------------------------------------------ We do not allow suid programs on exported, writable filesystems such as your home directory. This avoids the risk of this scenario: a cracker becomes superuser ("root") on one NFS client computer (such as a UNIX workstation in a lab), plants a set-uid-to-root program on the insecure NFS-mounted file system, logs into related NFS clients and servers as a non-root user and uses the program to become "root" on all those systems. We assume that the client systems in the labs are more vulnerable to root breakins than the servers are, if only because users can reach the power switch. So we limit suid programs to a filesystem that is exported read-only and is served from a system that does not allow user logins. That is the Instructional /share/b filesystem. Blocking this for "root" user (superuser) programs also blocks it for all other users. If you wish to run a suid program, the sys admins have to install the program on the /share/b filesystem for you. While that does create a hassle for users who wish to run their own suid programs, there is a work-around during the development of such a program. You could test the program by placing the suid binary in the /tmp directory on our UNIX computers, as /tmp is not exported and therefore not subject to the suid restriction. "ftp", "rlogin" and "telnet" are restricted on some systems ----------------------------------------------------------- In an effort to protect our UNIX systems from outside intrusions, we have denied certain types of login access to certain systems. You can use "ftp", "rlogin" or "telnet" to log into our UNIX "login servers". These are currently cory.eecs, torus.cs, po.eecs, parker.eecs, mamba.cs The UNIX workstations are more restrictive. "ftp" is blocked, as are the standard "rlogin" or "telnet" programs. To login remotely, you must use the Kerberos versions on "rlogin" or "telnet", or the "ssh" program. These protect your password from network sniffing. They are avaialable on all EECS and CS UNIX computers. Ssh is also available on NT systems. For more information about these programs, please see http://www-inst.eecs.berkeley.edu/usr/pub/ssh.help http://www-inst.eecs.berkeley.edu/usr/pub/kerberos.help Servers that are limitted to instructors and staff have restrictions too. If you are an instructor, please check with "root@cory.eecs" about that. EECS Instructional & Electronics Support 377 & 386 Cory, 333 Soda root@cory.eecs.berkeley.edu