Process Permissions

September 25, 2016

The operating system enforces a system of rights and permissions. Rights and permissions refer to permitted or restricted actions that one category of entity, the subject, performs on another category of entity, the object. Intuitively, the subject is a user and the object is something over which the user has jurisdiction. The operating system models this jurisdiction and attempts to enforce it.

For example, a certain user may have the right to read or modify a file. The file is the object and the user is the subject. The permitted action is to read or modify. Strictly speaking, it is never the user that takes the action, but a process working on behalf of the user. For this reason, the process is the central actor in the system of rights and permissions. A typical mechanism is for the process to have an owner, and the rights and permissions of the process are those of its owner.

To complete the access decision, there must be an object and a set of rules attached to the object-subject pair. If the rules are attached to the object, the rules are called permissions, and if attached to the subject, the rule are are called rights, also known as privileges. If the right or privilege is transferable to another subject, the transferable access is called a capability.

Traditional unix security was based on a permission system for files, and the unix principle that “everything is a file”. Hence a large number of activities passed through the file system and security enforced as a permission on an object. Activities that are more appropriately a right, such as the right to reboot the computer, depended on a simple distinction of subjects into root, with UID 0, and any other user (UID not 0). There was also from the start a group identifier, and that was expanded into the ability for creating collections of groups. However most security decisions were made using the three permissions read, write, and execute that could be applied to one of three subjects — the file owner, the group owner, or anyone else. If the subject is root, all is permitted.

The SUID bit

The permissions system of Unix required that a process have the proper ownership to accomplish the required tasks. Processes are created by fork as replicas of the forking process, so there needed to be a mechanism to modify process ownership. The setuid system call was permitted only to root, and if the process was owned by root, this call could change the ownership to any other user. This mechanism is too limited. For instance, if this were all there were to the mechanism it would be impossible for a user to change their own password. Passwords would be stored in a file, and that file must be changeable only by root. But any process run by a user would be owner user and therefore could not change the password file. Hence, a user could never change their own password.

The SUID bit was introduced into the permission system to allow enough flexibility to accomplish such tasks. The permission system included a set-uid property. If a program had the set-uid property, that is, the file that contained the program was marked set-uid, the exec system call changed the ownership of the process to that of the file, and the process now has the rights and permissions of the file owner, rather than those of the process parent.

The owner of a file has rights over the file’s permissions, hence this allowed the owner of a file to allow an arbitrary user to “borrow” the owner’s rights, but only during the run of the program. Since the owner wrote the program, the consequences of they borrowing would be under the file owner’s control, and hopefully the file owner will write a program that has no unintended consequences because of this borrowing. As described by Thompson and Ritchie:

The Since the actual user ID of the invoker of any program is always available, set-user-ID programs may take any measures desired to satisfy themselves as to their invoker’s credentials. – The UNIX Time-Sharing System, Dennis M. Ritchie and Ken Thompson Bell Laboratories, CACM 17:7 1974.

The unix version 1 man pages describe a real and effective UID. Exec would change the effective UID, but the real UID would be unchanged. The getuid system call would return the real UID, so that the program could make decisions based on the owner of the process that invoked this program. The setuid program would return an error if called by a process other than root-owned. Root could only set the real and effective UID to the same value.

By version 6, the definitive "porto-unix", getuid would return both the real and effective UID’s, and setuid could be invoked by other than root, but only to copy the real UID into the effective UID, thereby dropping the privilege of running as the program’s owner. Once the privilege was dropped, it could not be regained. Even root could not set the effective UID different from the real UID. This was the only possible through the combination of the exec system call and the suid permission bit on the file.

Various descendants of version 6 unix set about solving the problem of being able to drop privilege and then regain privilege in different ways, which introduced more heat than light, and also security bugs. For instance, Unix SYSV introduced the save uid, and a non-root user could set the effective uid to either the real or saved uid. For a full discussion see Setuid Demystified by Hao, Wagner and Dean.

Access Control Lists

The unix permission system is limited to the three permissions read, write and execute, interpreted variously depending upon whether the object protected is a file or directory, or other sort of filesystem resident entity, with the subjects: owner, group, other, and root. A more flexible permission system was needed, and in fact, to achieve government certification as C2 secure, according to the Orange Book standard, unix needed an improved system of access control.

An access list (ACL) is a list of rules, each rule matching a subject and ending in an accept or reject. The list of rules is attached to the object, so that the system is a system of privilege. Still unaddressed was unix’s simplistic privilege/rights system, such as the right to reboot or install or upgrade software. Some rights can be simulated by creating a filesystem object to represent the right, and then attaching a sophisticated ACL to the object.

The implementation of an ACL system for Linux was undertaken by the National Security Agency, NSA.

Rights and Capabilities

posted in CSC521 by admin

 
Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org