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
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.
