Skip to main content
CSE Unix Security Awareness

CSE Unix Security Awareness

This is a general discussion of computer security from the viewpoint of the user of a Unix system. This is what you can do for yourself to prevent them from hurting you. Topics include: account access, file permissions, file encryption, and known security loopholes you can plug for yourself.

Short security checklist:

  • Choose a good password.
  • Protect your password and do not share it with anyone.
  • Be aware of the permissions on your files and directories and what those permissions mean in terms of access for other users.
  • Never run a program that is in another user's directory or in /tmp or any other public space.
  • Report suspicious behavior or incidents to the system managers.
  • Use the self_check script regularly.


Unix system security is largely the responsibility of the system administrators. In managing our systems, we choose a middle ground between having so little security that any user can harm the system and having so much security that academic curiosity and the free interchange of knowledge is stifled. There is essentially a default level of security that you can accept, increase, or decrease according to your needs.

The default level of security is sufficient to protect your work from careless mistakes and naive attempts at tampering. However, for your own work to be reasonably secure, you must understand something about the Unix access mechanisms and what your responsibilities are in maintaining security.

This document is not intended to be a security tutorial. All the commands and methods discussed are standard parts of Sun Solaris unless otherwise indicated. For additional information, please see the manual pages and other Unix documentation.

The examples and command syntax shown are for the Solaris (System V) flavor Unix. The few SunOS (BSD derived) systems we still operate are somewhat different. The HP-UX systems in the Case Center also use the System V flavor of Unix and have similar commands and capabilities, but the syntax may differ slightly. The various versions of Unix are slowly converging on a standard set of commands.

Account Security

The single most important security measure you can take is to have a good, secure password; keep your password secret; and change your password whenever you think it may no longer be secret. It is a violation of CSE policy to share your password or your account with anyone.

A good password is composed of two or more small nonsense words and two or more non-alphabetic symbols or uppercase letters. For example: dog$waLL, 8bar3goo, I2pIne4u. Such passwords are easy to remember, yet are very difficult for people (or programs) to guess. You may enter a password of any length, but only the first eight characters are used.

File Access

A complete discussion of controlling access to your files and directories is covered in the Unix File Access Permissions and Access Control Lists documents.

The .rhosts file

Many people use a .rhosts file to allow using the rlogin, rsh, and rcp commands between systems in different labs or at different sites. If used improperly, this capability can be a serious security risk! Below is an example of a good .rhosts file. Do not create a .rhosts file containing an unqualified + symbol! This would open your account to easy attack from any of the millions of machine on the Internet around the world.

  

+@cse lees
ozma.emerald.city.oz lees

Data Encryption

The vi text editor has a -x option for working with encrypted files. If invoked with the -x option, you are prompted for a key used to encrypt (or decrypt) the file you are editing. Within vi, the :X command is used to encrypt the current file.

Outside of vi you can use the crypt command to encrypt or decrypt a file. First use gzip to compress the file, then use crypt. See the man pages for more information.

Of course you must decrypt a file to use it. This makes the file at least temporarily vulnerable. You can shorten this vulnerability by using crypt in a pipe:

  

gzip [file] | crypt [key] | lpr -Psomeprinter

WARNING: If you encrypt a file and forget the encryption key, you are out of luck. There is no way we can help you recover your file!

File Backups

The ultimate security against loss of your work is good backups. Our normal backup schedule tries to prevent the loss of more than one day's work in the event of a system malfunction or other file loss or damage.

Common Sense

There are several other steps you might want to take to remove some of the sharp corners of Unix.

Ooops

The default login shell on the CSE systems is the C shell (/bin/csh). Our standard .cshrc file contains these commands:

  

set noclobber
alias cp 'cp -i'
alias mv 'mv -i'
alias rm 'rm -i'

The -i option causes the command to ask for confirmation before a file is written over or removed. The noclobber switch prevents you from redirecting output to an existing file unless you permit it by using >! syntax. If you use other than the C shell, please set up your dot files to provide similar protection.

Trojan horses

One of the time honored ways to break into an account is to write a program that will change access permissions, and then trick other users into running the program. So it is not wise to execute programs that reside in other users' directories or in public places like /tmp. You may be giving away access to your files.

For the same reason you should not have "." (the current directory in your path). Consider what happens if a nasty person plants executable files in /tmp having names like "ls" and "cd". Even if "." is last in your path, you can be caught by trojan horses having names like "sl", "csl", and so on.

Another favorite trick is to write a program that makes the monitor look like the standard login screen. When you try to login the program captures your username and password and then dies, making it look like you typed your password incorrectly. In practice this is very difficult to do in such a way that the bogus login screen looks and feels completely correct.

The message here is pay attention and do not take for granted the security of your computing environment.

The self_check script

We have a perl script named self_check you can run that checks your files for a lot of the standard permission problems. We don't guarantee that it catches all problems, but it is a good start.

The clean_me script

It's not a security thing, but we also have a script named clean_me that helps you get rid of unwanted files. Do "clean_me -h" to see the options.