The purpose of a protection system is to prevent accidental or intentional misuse of a system.
- Accidents: Problems of this kind are easy to anticipate (It’s possible to take action to minimize the likelihood of an accident).
- Malicious abuse: Problems of this kind are very hard to completely eliminate (In order to protect completely against malicious abuse, one must anticipate and eliminate every loophole and resist any temptation to play on probabilities).
There are three aspects to a protection mechanism:
- User identification (authentication): make sure we know who is doing what.
- Authorization determination: must figure out what the user is and is not allowed to do. Need a simple database for this.
- Access enforcement: must make sure there are no loopholes in the system.
Even the slightest flaw in any of these areas may ruin the whole protection mechanism.
Authentication
User identification is most often done with passwords. This is a relatively weak form of protection.
- A password is a secret piece of information used to establish the identity of a user.
- Passwords should not be stored in a readable form. One-way transformations should be used. A 1-way function is an interesting function that is relatively easy to compute, but difficult to invert (essentially the only way to invert it is to compute all the forward transforms looking for one that matches the reverse).
- Passwords should be relatively long and obscure.
- Systems like UNIX(R) don't store the password, but the result of a 1-way function on the password. To check a user's password, the system takes the password as input, computes the 1-way function on it, and compares it with the result in the password file. If they match, the password was (with high probability) correct. Note that even knowing the algorithm and the encrypted password, it's still impossible to easily invert the function.
Although it's theoretically reasonable to leave a hashed password file in the open, it is rarely done anymore. There are a couple reasons:
- In practice, bad passwords are not uncommon enough, so rather than having to try all the passwords (or half the passwords on average), trying a large dictionary of common passwords is often enough to break into an account on the system.
- Password file can be attacked off-line, with the system under attack completely unaware that it is under attack. By forcing the attacker to actually try passwords on the system that they're invading, the system can detect an attack.
Another form of identification: badge or key.
- Does not have to be kept secret.
- Should not be able to be forged or copied.
- Can be stolen, but the owner should know if it is.
Key paradox: key must be cheap to make, hard to duplicate. This means there must be some trick (i.e. secret) that has to be protected.
Once identification is complete, the system must be sure to protect the identity since other parts of the system will rely on it.
Authorization Determination
Must indicate who is allowed to do what with what. Draw the general form as an access matrix with one row per user, one column per file. Each entry indicates the privileges of that user on that object. There are two general ways of storing this information: access lists and capabilities.
Access Lists: with each file, indicate which users are allowed to perform which operations.
- In the most general form, each file has a list of pairs.
- It would be tedious to have a separate listing for every user, so they are usually grouped into classes. For example, in Unix there are three classes: self, group, anybody else (nine bits per file).
- Access lists are simple, and are used in almost all file systems.
Capabilities: with each user, indicate which files may be accessed, and in what ways.
- Store a list of pairs with each user. This is called a capability list.
- Typically, capability systems use a different naming arrangement, where the capabilities are the only names of objects. You cannot even name objects not referred to in your capability list.
- In access-list systems, the default is usually for everyone to be able to access a file. In capability-based systems, the default is for no-one to be able to access a file unless they have been given a capability. There is no way of even naming an object without a capability.
- Capabilities are usually used in systems that need to be very secure. However, capabilities can make it difficult to share information: nobody can get access to your stuff unless you explicitly give it to them.
Are the following things access-based or capability-based protection schemes?
- Protection Keys
- Page tables
Access Enforcement
Some part of the system must be responsible for enforcing access controls and protecting the authorization and identification information.
- Obviously, this portion of the system must run unprotected. Thus it should be as small and simple as possible. Example: the portion of the system that sets up memory mapping tables.
- The portion of the system that provides and enforces protection is called the security kernel. Most systems, like Unix, do not have a security kernel. As a consequence, the systems are not very secure.
- What is needed is a hierarchy of levels of protection, with each level getting the minimum privilege necessary to do its job. However, this is likely to be slow (crossing levels takes time).
File System Security
The problem addressed by the security system is how are information and resources protected from people. Issues include the contents of data files which are a privacy issue, and the use of resources, which is an accounting issue. Security must pervade the system, or the system is insecure, but the file system is a particularly good place to discuss security because its protection mechanisms are visible, and the things it protects are very concrete (for a computer system).
We're talking about some interesting stuff when we talk about security. For certain people who like puzzles, finding loopholes in security systems and understanding them to the point of breaking them is a challenge. I understand the lure of this. Remember, however, that everyone using these machines is a student like yourself who deserves the same respect that you do. Breaking into another person's files is like breaking into their home, and should not be taken lightly either by those breaking in, or those who catch them. Uninvited intrusions should be dealt with harshly (for example, it's a felony to break into a machine that stores medical records). If you really want to play around with UNIX(R) security, get yourself a linux box and play to your heart's content; don't break into someone's account here and start deleting files.
Policies and Mechanisms
Policies are real world statements about the protection that the system provides. These are all statements of (significantly different) policies:
- Users should not be able to read each other's mail
- No student should be able to see answer keys before they are made public
- All users should have access to all data.
The various systems in a computer system that control access to resources are the mechanisms that are used to implement a policy. A good security system is one with clearly stated policy objectives that have been effectively translated into mechanisms.
The fact that data security does not stop with computer security cannot be understated. If your computer is perfectly secure, and an employee photocopies printouts of your new chip design, don't blame the computer security system.
Design Principles
Although every security system is different, some overriding principles make sense. Here is a list generated by Saltzer and Schroeder from their experience on MULTICS that remain valid today (these are fun to apply to caper movies - next time you watch Mission Impossible or Sneakers or War Games, try to spot the security flaws that let the intruders work their magic):
- Public Design Surprisingly public designs tend to be more secure than private ones. The reason is that the security community as a while reviews them and reports flaws that can be fixed. Even if you take pains to keep the source code of your system secret, you should assume that attackers have access to your code. The bad guys will share knowledge, the good guys should, too.
- Default access is no access. This holds for subsystems just like login screens. It sounds like a platitude, but is a principle worth following at all levels. People who need a certain access will let you know about it quickly.
- Test for current authority Just because the user had the right to perform an operation a millisecond ago doesn't mean they can do it now. Test the authority every time so that revocation of that authority is meaningful.
- Give each entity the least privilege required for it to do its job. This may mean creating a bunch of fine-grained privilege levels. The more privilege an entity possesses the more costly a mistake or misuse of that entity is. Printer daemons that run as root can cause logins that run as root.
- Build in security from the start. Adding security later almost never works. There are too many holes to plug, and as a practical matter security is nearly impossible to add to a fundamentally insecure system.
- In order to make such a design integration, it must be simple and capable of being applied uniformly.
- The system must be acceptable to the users. All security systems are a compromise between security and usability. The more features a system has, the more likely opportunities there are for exploitation. Furthermore, if a security feature is too onerous to the users, they will just invent ways to circumvent them. These circumventions are then available for the attackers. An unacceptable security system is automatically attacked from within.
A Sampling of Protection Mechanisms
The idea of protection domains originated with Multics and is a key one for understanding computer security. Imagine a matrix of all protection domains on one axis and all system resources (files) on another. The contents of each cell in the matrix are the operations permitted by a process (or thread) in that domain on that process.
| Domain | File 1 | File 2 | Domain 1 | Domain 2 |
| 1 | RW | RWX | - | Enter |
| 2 | R | - | - | - |
Notice that once domains are defined, the ability to change domains becomes another part of the domain system. Processes in given domains are allowed to enter other domains. A process's initial domain is a function of the user who starts the process and the process itself.
While the pure domain model makes protection easy to understand, it is almost never implemented. Holding the domains as a matrix doesn't scale.
Some Domains and Rings
UNIX divides processes into 2 parts, a user part and a kernel part. When running as a user the process has limited abilities, and to access hardware, it has to tap into the kernel. The kernel can access all OS and hardware, and decides what it will do on a user's behalf based on credentials stored in the PCB.
This is a simplification of the MULTICS system of protection rings. Rather than 2 levels, MULTICS had a 64 ring system where each ring was more privileged than the ones surrounding it, and checked similar credentials before using its increased powers.
