Protection in Operating Systems: Section 19.1 through 19.5 of the book; section 19.2.2.2 is not required; ----------------------------------------------------------------------------- Protection mechanisms that we have talked about before: . user mode / kernel mode; . only root or administrator can change the kernel code; . Every process' address space is separated from every other process' address space; . Every file has an access control list; Now, let's bring the material together and take a systematic look at protection in OS. ------------------------------------------------------------------------ Protection Domain: a collection of access rights, each of which is a pair . Examples: 1. Kernel can be thought of having a kernel domain. The kernel domain has all rights to all objects and resources, for example, the kernel domain has read and write rights to all processes' address spaces; Each user process may be thought of having its own domain. Its rights include read and write to its own address space, but its rights do not include read or write to any other processes' address space. 2. In UNIX, each user is associated a protection domain. For example, user "cao"'s protection domain includes read and write rights to all files under ~cao/, and read and write rights to all files under ~cs537-2/; user "studentA"'s protection domain includes read and write rights to all files under ~studentA/, and read and write rights to files under ~cs537-2/handin/studentA/. In UNIX, everytime a user starts a process, the process runs in the protection domain associated with the user. Every operation made by the process is checked against the rights in that protection domain. For example, user "cao" may start a process "cat", to cat "~cs537-2/private/grades", this means open and read the file ~cs537-2/private/grades, which is allowed in the protection domain of user "cao". However, studentA would not be able to cat the file since his or her protection domain does not have the rights. To handle cases such as changing the password file /etc/passwd, UNIX provides a "setuid" facility. Each file may have its "setuid" bit set to 1. If a file has its setuid bit being 1, then when a process is created using this file as the binary executable, the process runs in the protection domain associated with the owner of the file, not the user who creates the process. Thus, in older UNIX systems, /bin/passwd program has its setuid bit as 1 and its owner is root. Thus, when a user type "passwd" to change his or her password, the process actually runs in the root's protection domain, which has the right to change the password file /etc/passwd. However, the setuid feature in UNIX causes more grief to computer security experts than any other feature in UNIX. For example, what someone manages to overwrite /bin/passwd so that its contains the binary of the shell program? That person can then type "/bin/passwd", and actually get a shell process started as root (since overwriting a file doesn't change its owner or setuid bit)! That person can then do anything to the system. For this reason, the CSL checks regularly all system binaries on the department machines to make sure that they have not been changed. Another way is to trick the system administrator to create a file with the administrator as the owner and the setuid bit as 1. If the file is the shell program, then someone else can simple run the file and become the administrator. A better way to handle cases such as changing passwords is to have a daemon process started by the kernel and to let the process wait for requests to change passwords. The passwd process then simply send the user's request to the daemon process. This approach is adopted in some operating systems. 3. In Java, the latest Java security mechanism associates a protection domain with each applet. There are a few broad-category protection domains, such as "GameWare", "Financial Software", etc. Each Java applet is associated with a domain based on who provides the applet. For example, an applet from www.doom.com would have the domain "GameWare". Each domain has its own rights to various objects and devices. For example, domain "GameWare" would have write access to both audio and video devices. In Java, a thread enters into a protection domain A (that is, having the rights for that domain) when its calls a procedure in an applet whose domain is A. It exits the domain A when that procedure returns. Thus, the thread switches domains based on the code that it is executing, entering into a domain when calling an applet in that domain, and exiting it when the call returns. ------------------------------------------------------------------------------- Access permission matrix (section 19.3): a matrix with domains as rows, and objects as columns, and whose entries indicate the rights of a particular domain on the object; . it is a conceptual model to think of the access rights that domains have on objects; . To see whether a process executing in Domain Di has read or write permission to object Fj, just need to check the entry in the access permission matrix; . the access permission matrix must be protected and no user should be able to write it; only trusted code (for example, the kernel) can change it; Encoding other rights in Access permission matrix: . each domain can be viewed as an object, and other domains may have the "switch" right to the domain. That is, if the entry corresponding to row i and column k has "switch" right in it, and column k corresponding to domain Dj, then a process executing in domain Di can switch to domain Dj; . a domain may be the owner of an object, in which case a process executing in the domain can grant rights to the object to other domains, or revoke rights to the object from other domains. In other words, if the entry has "owner" right in it, then domain Di can change all entries in column j. Storage of Access permission matrix: . if the matrix is stored by columns, each column j is also called the "access control list" for the object Fj; . if the matrix is stored by rows, each row i is also called the "capability list" for the domain Di; . both forms of storage are equivalent in terms of functionality, but have different implications for the structure of the OS;