Security

The Insides of Athena Unix

Today we are going to talk about Unix security.  The first topic will be the first security system you run across when using Unix.

[] Password Security

Next we will talk about some of the implications of the networking programs which are available.

[] Networking

We will then talk about what it means to protect a file

[] File Security

After that, we will discuss ways for keeping information even more private should you decide to do so.

[] Encryption

I have no intention on teaching you how to break into a system. Instead, I hope to point out some of the things you should do to make sure that you are not the victim of someone elses attempts to breach security.

———————————————————————-
[] General Overview

UNIX is not a „secure“ operating system.  It really wasn’t designed to be one, though.  But, what do we mean by security?  Let’s start by considering several types of security.  There is physical security. This is made up of things like locks on doors, and the Campus Police. For some systems this is sufficient.  For instance, if a computer, and all the terminals which can connect to it are in a locked room, then the system is as secure as the lock on the door is. 

What happens, though, when you add a dialup?  Or a network?  No machine which can be accessed from the outside should be considered secure.   The first line of defense is passwords though.  The idea is to keep people who aren’t supposed to be using the machine from being able to do so.  If they can’t do anything at all, then their not going to be breaking security.  Of course, not all password systems are so great.  It is often possible to obtain passwords by guessing them, or
through various other means.

The last type of security is of particular importance to Athena.  What do you do in an anvironment where lots of people have accounts, but not all these people can be trusted.  You need some way of controlling access to resourses such that people have access to their own files (or other files in certain ciscumstances), and only limited (if any) access to other peoples files.  It is at this level that keeping a system secure becomes a problem because the potential intruder has so many more attacks he can try.

[] Password Security

Let me start by talking about password security.  Under UNIX, passwords are stored in the /etc/passwd file.  This is a publicly readable file, so clearly, something has to be done to protect the passwords.  Passwords are encrypted in such a way that they can not be converted back into the plaintext they were generated from.  When you log in, the system asks you for your password, it then encrypts the password, and compares the encrypted version to what is stored in the /etc/passwd file. 

There are several attacks to breaking this security method.  One approach is brute force.  An attacker tries all possible passwords until he finds the correct one.  This attack is impractical because of the time required. 

Fortunately (for the attacker), most people choose common passwords. There username, their name, or words that are in the dictionary.  In one experiment (described in „Password Security: A Case History“ by Robert Morris and Ken Thompson), 3,289 passwords were collected over a along period of time.  Of these,

15 were single ASCII characters
72 were strings of two ASCII characters
464 were strings of three ASCII characters
477 were four alphanumeric characters
706 were five letters either all upper, or all lower case
605 were six all lower case letters

492 appeared in various available dictionaries

A few things have been done to make things more difficult for the attacker.  An encryption algorithm is used that takes a lot of time to run.  This tends to increase the time required to guess passwords. Passwords are also „salted“.

One attack that has been used is to come up with a dictionary of encrypted passwords, and compare the encrypted password in the password file with the encrypted dictionary.  This takes a lot less time per entry than having to encrypt the plaintext word you want to test, and then comparing it to the encrypted password.  Salting a password means that a random number is selected when the password is initially created, and added to the plaintex before it is encrypted.
This random number is then also added to the encrypted password before it is written to the password file.  When a password is checked, the same random number is taken from the encrypted password, appended to the plaintext which is then encrypted, and the result compared with the encrypted password.

Salting the password means that there are now 4096 versions of each password that are possible.  Thus, an attackers dictionary would have to be 4096 times as large.

[] Networking

The availability of remote login and remote execution in a networking environment (as exists with Athena) introduces many new ways to breach system security.  The problem is how to authenticate users across the network without requiring them to enter their password again.  The way this has been accomplished is through the concept of a „safe host“.  A job can log in, or remotely execute commands without a password only if the user is logged in from a „safe account“ on a „safe host“.

Networking has presented many other problems for system security, but I do not intend to discuss them at this time.

———-
[] File Security

What does it mean to protect a file?

Under UNIX, there are several fields in the protection of a file.  The first three bits control access to the file by its owner.  The next three define the access by other people in ones group (people in the group that owns the file).  On Athena, most peoples groups are „mit“, so this group field is really just another field for „world“.  The last set of three bits define the access for everyone else.

The bits on a file control read, write, and execute, but one also needs to be concerned with the protection bits on directories.  If someone has write access to a directory, then they can create, and delete files contained in it.   Read access to a directory gives one permission to look at the directory (with ls for example). Execute access conveys permission to connect to the directory and to search it for a file which you know the name of.

It is also important to note that someone with access to the root account can read, or write ANY file on the system regardless of the protection.  Pleople who have this access include Athena staff, some consultants,  some system wizards, and occasionally someone who has managed to break the systems security.  On Charon, certain SIPB member have root access.

When you log in, your .login sets a „umask“ which defines the default protection you want to give files you create.  This mask is 3 octal digits defining the bits that you DO NOT want to appear in the protection for the various entities (owner, group, and world). Further, if you have given niether read, nor execute access to a directory, then other users will not be able to access files beneath that directory regardless of the protection of the individual file.

[] Encryption

As you can see, there is no way to keep a file totally secure under UNIX.  Since the file can’t be secure, you may want to use encryption to keep the contents secure.  Currently there is a program called crypt which can be used to encrypt files.  Unfortunately, the algorithm used in crypt has been broken.  In the near future, Athena will be distributing a new algorithm (I believe based on DES) to replace crypt.  This algorithm is believed to be more secure.

• Unix Course: Introduction, Shell Commands – Lecture 1
• Unix Course: The Shell, and Shell Programming – Lecture 2
• Unix Course: More Shell Programming – Lecture 3
• Unix Course: Unix Security – Lecture 4