1. Introduction: Security Problems
2. Authentication
1. Methods of Authentication
2. Internal vs. External
1. External: Passwords
2. Internal: Process Table
3. Authorization
1. Scaling
1. Access Control List
2. Role-Based Access Control
3. Capability
4. Trusted Software

In our vast and constantly growing world of computer technologies, confidential information stored in the form of 0's and 1's are exposed to risks of theft. Like the bolts on our front doors and the locks on file cabinets of business offices, the privacy of our data is vital. Similar to metalworkers crafting stronger and more effective locks on doors against attackers, programmers must also develop stronger and more effective methods of keeping computer systems secure against attackers.

Authentication is the process of verify that the accessor of the system is truly who they claim to be. There are three methods to accomplish this:

• WHO the principal is
• What the principal HAS
• What the principal KNOWS

Authentication by the identity of the principal is achieved by using biometrics, the use of human characteristics and traits for identification. A popular biometric authentication used is fingerprinting, since all humans have unique ridge patterns on the surface of their fingertips. Other methods include retina scans, facial recognition, and DNA matching.

Authentication by an object owned by the principal often takes the form of a physical key. This is a more inferior and archaic form of authentication by identity, but is easily implemented and more versatile.

Authentication by a piece of knowledge known to the principal and the principal only is the most commonly used form of authentication because of its simplicity in both implementation and practical applications. Often, the principal simply has to remember a passphrase and input it when requested to be authenticated. This passphrase ranges from a simple 4-digit bank PIN number to that 10 character password containing alphanumerical and special characters used to log into your favorite forum.

Lets imagine a military base or the backstage of a concert. In order to enter, a person must be authenticated for entry. Before allowed entry, you must show some form of identification indicating who you are. After authentication is successful and entry is permitted, you are given a badge or pass to confirm your previous authentication. We can categorize these two authentication systems as external and internal."

External authentication is usually the first stage of authentication. For example, when accessing seasnet, we are required a standard username and password in order to login and access our files. Although easy to use and implement, there are various ways to attack a password, as well ways to defend it.
Passwords must be easily remembered, but it cannot be so easy to remember that it becomes easy to guess. A password is susceptible to some of these attacks:

• Dictionary Attack: A brute force attack where the attacker attempts to authenticate using common words combinations and passwords.
  Defense: The easiest defense against attacks like these are to limit the number of attempts allowed to authenticate. Other defenses include using automatically generated passwords provided by the OS.
• Social Engineering: An indirect attack in which victims are tricked into divulging their information. The attacker lures the victim into giving up their information by appealing to the victim's susceptibility to social convention.
  Defense: Extremely sensitive information should be authenticated not by the principal's knowledge, but one of the other methods of authentication.
• File Leak: Sysadmins leak the password file and user's passwords are compromised.
  Defense: Users need to be notified that their passwords need to be changed. Another defense would be encrypting or salting the keys so attackers will have more difficulty obtaining the passwords. Salting a password involves adding adding random data provided by the OS concatenated to the password.
• Snooping: A direct attack in which attackers obtain passwords by use of video cameras to or snooping packets off the network.
  Defense: Making workspaces and terminals covered is an easy physical protection. For example, many bank pin pads have a plastic cover to prevent snooping. Preventing packet snooping requires encryption between client and server, such as a cryptographic protocol.
• Fraudulent Servers: A phishing attack where the attacker develops a similar looking webpage to a trusted page, such as an online banking login page. This fake webpage obtains the victim's username and password, and then redirects them to the real site, avoiding detection.
  Defense: The only defensive measure that is effective against phishing is user awareness. They must make sure they only click trusted links.

Despite these weaker areas or passwords, they are extremely effective when properly made. An unguessable password, careful user, and impregnable server means a password is almost completely guaranteed to authenticate correctly.

After obtaining access to the system using an external authentication, the user can't simply be allowed to access everything. To regulate this, we use the process table. Each entry in the process table has uid and gid fields. On system calls, the OS will rely on these uid and gid entries to detmerine whether access to these system calls will be granted.

Authorization can be described as the the ability for the principal to do a certain action to a particular resource. This can be visualized as a 3 dimensional graph portrayed as a rectangular prism:

Using this visualization, taking points G and P depicted by their corresponding color, we can see they have an X, Y, and Z parameter which defines a particular user trying to do a certain action on a specific file. If we define the points as booleans, then G and P can describe something such as:

• G: User 3 can read to file A.
• P: User 2 can write to file C.

What we want when implementing authorization is space-utilization and effeciency. With so many resources in any given system, creating a 3-dimensional array would be very resource inefficient and snail-paced slow. Unix avoids this using the simple permissions system using owners, groups, and boolean modes. Modes are operations which allows the user categories to do read, write, execute, and setuid operations.

The downfall of unix's system is that it has difficulty scaling to larger systems. For example, if Dr. Eggert creates a directory:

/u/class/fall14/cs111

If Dr.Eggert wants to give TA's A, B, and C read, write, and execute access, then Dr. Eggert would have to create a group called CS111a and give it access. All other users would get read and execute access. The permissions Dr. Eggert would need to setup to make this work would be:

drwxrwxr-x eggert cs111a

However, setting up this up would require root access. When doing permissions like these, we want more flexibility so even users can set proper permissions.

Access Control Lists use the Unix permission system, but is on an individual level located in the inode. Inside the inode we can have a pointer that points to ACL metadata. From our previous example, we can set up the directory so that its ACL pointer gives TA A, B, and C the rwx properties. We can consider these exceptions to the file, so there will be no need to go to root to setup a group. We simply need to use the commands:

$setfacl
$getfacl

to adjust and view, respectively, the ACL pertaining to the file. Only the owner is allowed to set the ACL, which answers to our flexibility issue.

Another way of making permissions flexible is the idea of role-based access control(RBAC). The idea of RBAC is to assign users a role, which comes supplied with predeterminated permissions based on that user's role. For example, if we return to our previous example with Dr. Eggert, let us imagine a scenario where Dr. Eggert has been with UCLA for ten years, building up access to hundreds of resources. If there is a bug in permissions, then Dr. Eggert may get permission to say, adjust TA salaries, and all the programs that run under Eggert would get permission to TA salaries. The solution to this would be to assign roles to the individuals. This way, only payroll employees have the payroll role and Dr. Eggert cannot adjust TA salaries.

Capability is a form of access control attached to objects. It usually takes form as an encrypted pointer to said object. Unix's implementation of this are file descriptors, although file descriptors are not really encrypted, and the information is kept on kernel. We have client who authenticates to a server. If the server accepts, then it sends a key to a file back to the client, which allows access to another client. This is known as passing capabilities.

We come to the final security issue that plagues every system in existence. How can users truly trust the system they are currently on? In truth, users can never trust code that they did not write. Ken Thompson, one of the original developers of Unix, developed a hack which created a security backdoor in any system. He did this by rewriting the compiler to compile a flaw that created a security backdoor.

Of course, this sort of vulnerability could easily be detected by a debugger, so this hack was never really a threat. However, this point was highlighted by Ken in his speech "Reflections On Trusting Trust" because of the idea that there is no way to truly make everything completely secure.
If you don't trust software you didn't compile yourself, you must trust your operating system. If you compile the operating system yourself, you must trust the compiler. If you compile your own compiler, you must trust that compiler. And even if that is truly trustworthy, you must trust the actual hardware. In security, the user must be as paranoid as possible and trust no one, but unless all code is written by the user, the user must always trust someone.