You are here: Home » Content » Protection and Security
Content Actions
Quality
Affiliated with  (?)
This content is either by members of the organizations listed or about topics related to the organizations listed. Click each link to see a list of all content affiliated with the organization.
Lenses
Tags  (?)
These tags come from the endorsement, affiliation, and other lenses that include this content.

Protection and Security

Module by: Duong Anh Duc

Summary: Protection and Security

Protection and Security

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.

Security Improvements, Encryption

Security Improvements

Solutions: nothing works perfectly, but here are some possibilities:
  • Logging: record all important actions and uses of privilege in an indelible file. Can be used to catch imposters during their initial attempts and failures. E.g. record all attempts to specify an incorrect password, all super-user logins. Even better is to get humans involved at key steps (this is one of the solutions for EFT).
  • Principle of minimum privilege ("need-to-know" principle): each piece of the system has access to the minimum amount of information, for the minimum possible amount of time. E.g. file system cannot touch memory map, memory manager cannot touch disk allocation tables. This reduces the chances of accidental or intentional damage. Note that capabilities are an implementation of this idea. It is very hard to provide fool-proof information containment: e.g. a trojan horse could write characters to a tty, or take page faults, in Morse code, as a signal to another process.
  • Correctness proofs. These are very hard to do. Even so, this only proves that the system works according to spec. It does not mean that the spec. is necessarily right, and it does not deal with Trojan Horses.

Encryption

Key technology: encryption. Store and transmit information in an encoded form that does not make any sense.
The basic mechanism:
  • Start with text to be protected. Initial readable text is called clear text.
  • Encrypt the clear text so that it does not make any sense at all. The nonsense text is called cipher text. The encryption is controlled by a secret password or number; this is called the encryption key.
  • The encrypted text can be stored in a readable file, or transmitted over unprotected channels.
  • To make sense of the cipher text, it must be decrypted back into clear text. This is done with some other algorithm that uses another secret password or number, called the decryption key.
All of this only works under three conditions:
  • The encryption function cannot easily be inverted (cannot get back to clear text unless you know the decryption key).
  • The encryption and decryption must be done in some safe place so the clear text cannot be stolen.
  • The keys must be protected. In most systems, can compute one key from the other (sometimes the encryption and decryption keys are identical), so cannot afford to let either key leak out.
Public key encryption: new mechanism for encryption where knowing the encryption key does not help you to find decryption key, or vice versa.
  • User provides a single password, system uses it to generate two keys (use a one-way function, so cannot derive password from either key).
  • In these systems, keys are inverses of each other: each one could just as easily encrypt with decryption key and then use encryption key to recover clear text.
  • Each user keeps one key secret, publicizes the other. Cannot derive private key from public. Public keys are made available to everyone, in a phone book for example.
Safe mail:
  • Use public key of destination user to encrypt mail.
  • Anybody can encrypt mail for this user and be certain that only the user will be able to decipher it.
It is a nice scheme because the user only has to remember one key, and all senders can use the same key. However, how does receiver know for sure who it is getting mail from?

Digital Signatures

Positive identification: can also use public keys to certify identity:
  • To certify your identity, use your private key to encrypt a text message, e.g. "I agree to pay Mary Wallace $100 per year for the duration of life."
  • You can give the encrypted message to anybody, and they can certify that it came from you by seeing if it decrypts with your public key. Anything that decrypts into readable text with your public key must have come from you! This can be made legally binding as a form of electronic signature.
This is really even better than signatures: harder to forge, and can change if compromised. Note that this idea was developed by an undergraduate (Loren Kohnfelder) in 1978 as part of his undergraduate thesis (at MIT).
These two forms of encryption can be combined together. To identify sender in secure mail, encrypt first with your private key, then with receiver's public key. The encryption/decryption functions to send from B to A are:
Encryption appears to be a great way to thwart listeners. It does not help with Trojan Horses, though.
Old federal Data Encryption Standard (DES). Is not public-key based, but has been implemented efficiently and appears to be relatively safe.
New Advanced Encryption Standard (AES), called Ryndal.
General problem: how do we know that an encryption mechanism is safe? It is extremely hard to prove. This is a hot topic for research: theorists are trying to find provably hard problems, and use them for proving safety of encryption.
Summary of Protection: very hard, but is increasingly important as things like electronic funds transfer become more and more prevalent.

Acknowledgment

We would like to thank Prof. Barton Miller for sharing as well as for his valued advice

Comments, questions, feedback, criticisms?

Send feedback