Imagine there is an army base, and at the entrance of this army base is a guard. This guard's responsibility is to ask anyone who tries to enter for their proper security clearence, and if that person passes they are granted access to the base. This is an example of external authentication, in order to access a device a password or key must be entered by the user. External Authentication is a more strict form of checking, and is slower than it's counterpart, internal authentication explained below. However, there are many problems with authentication based on a passoword, such as:
There are way to defend yourself against the possible attacks mentioned above, such as:
Back to the army base example, as we know the guard outside was external authentication preventing malicious users from getting into our base/system. Internal authentication would be analogous to swiping an access card going from building to building within the base. It is a much quicker and lenient form of checking since it is given that the user has already been authenticated.
In Unix/Linux, internal authentication is done via the process table. Within the process table are two entries the UID (user ID) and GID(group ID). These entried cannot be changed, unless the user has root access. With root access the user can call the functions like setuid(u, g) which sets the user id to 'u' and group id to 'g'. If an executable has the setuid bit enabled in its node its user accessesibility would be: 100 rwxr-xr-x. The first 3 bits here encode for the decimal number 4 and gives the process the filed uid.
setuid programs provide protected transfer of control
Authorization is how to keep track of what a process can do, or is allowed to do.
Depicted above, authorization can be modeled by a cube where the three axis correspond to the principle users, the resources or the files, and the actions or operations that users might want to do. For every pixel in this cube, the process is either capable or not capable of executing the particular action on the particular file. In other words each pixel has attached to it a value of yes or no, regarding whether the action is legal or not.
In Unix, files have owners + groups + modes. Modes are which operations are allowed for each category (self, group, etc...). Processes only have owners + groups. Let's say for example Dr. Eggert creates a directory '/u/class/fall14/CS111' and wants TA's A, B, and C to get rwx access to it but everyone else only r-x access. To do this we can create a group called CS111_TA, we can then add users A, B, and C to this group and change the access rights of that group.
The way we can create the group and change there accessibility, like mentioned above, is through access control lists. They are a form of metadata embedded within the inode of a file. They define the privelages that users (principles) have for a particular resource. They contain Access Control Entities which specify accessibility for each user within a group.
Although ACL's present an elegant solution to our problem, they have a catch. Individuals have access to many resources, and can possibly get too much power that they rather should not have. For example Dr. Eggert has many ACL's. He has a program grading.sh that is to be used by TA's to grade our assignments, withint grading.sh there is a bug that changes TA's salaries. We would rather not want grading.sh (the specific program) to have access to TA's salaries even if Dr. Eggert has access to both.
The solutions for the problem mentioned above is to assign "roles". Where each role only has particular accesses, and each user only has particular roles. For example, in our Computer Science Dept. example we can have roles such as, graders, course designers, and software developers. Each of these roles can have different permissions to different files. RBAC's are more complicated to implement.
Capabilities allow us to control object access by encrypting a pointer to the object, which means we no longer need the kernel anymore to enforce protection. We can send capabilities to other clients on the same network. There are issues with capabilities, however, for example people can forge capabilities and send false capabilities to people. Another issue is that a server must contain that capabilit. Each server must prevent clients from leaking the capability.