Chapter 14: Protection

Chapter 14: Protection Chapter 14.1 Goals of Protection Principles of Protection Domain of Protection Access Matrix Chapter 14.2 Implementation of Access Matrix Access Control Revocation of Access Rights Capability-Based Systems Language-Based Protection

Objectives Discuss the goals and principles of protection in a modern computer system Explain how protection domains combined with an access matrix are used to specify the resources a process may access Examine language-based protection systems

Background Protection and Security are related yet very different topics. We will devote a chapter to each. Protection requires two things: A Policy – what it is we want, and Implementation mechanisms – how we are going to do it. Protection is a measure of confidence that the integrity of a system and its data will be preserved. Security assurance is a much broader topic and we will cover it next chapter. One may view Protection as some kind of mechanism for controlling access of programs, processes, or users to resources defined by a computer system – perhaps system resources; perhaps user resources. The mechanism for implementing these controls must be specified. And there must also be a means of enforcement and not simply policy.

Goals of Protection We know that operating systems consist of large collections of objects, hardware and software All users of such a computer system share these same resources. Clearly, we need to protect these shared resources from intentional or accidental activities which may prove to be disastrous. Since all these resources are shared, we definitely need policies to govern and control appropriate access. Specifically, policies need to define authorized and unauthorized access.

Policy and Implementation - 1 Policies may be fixed in the design of the computing system Other policies may be developed by management of the computing system. Still other policies may be implemented by users themselves to protect their own files and programs. Thus a protection system must include the ability to enforce a number of different policies. Operating system designers can implement protection mechanisms as integral parts of the OS (a protection kernel perhaps). Application develops may also develop protection mechanism and in some cases these desires are supported by their choice of programming language. While these will clearly differ in scope and extent, both are needed. We now define an object as a unique name that can be accessed through a well-defined set of operations. So, the protection problem is to ensure that each object is accessed correctly and only by those processes allowed to do so.

Policy and Implementation - 2 In this chapter, we will emphasize what an operating system can/should provide. Using these facilities, an application developer may then select some of his/her own protection approaches, as mentioned. Note that having mechanisms – ‘how’ something will be done, differs markedly from policies, which address ‘what’ will be done. Policies can change from time to time. Conceivably, policy changes may result in changes to underlying mechanisms. This is always the way things are done: The ‘what’ followed by the ‘how.’ Clearly related, but vastly different!

Principles of Protection The criterion that is used to guide design and implementation issues for protection is the principle of least privilege. Basically, this principle says that ‘one’ should have enough privileges to do what one needs to do but nothing more! One of the advantages of this approach is that if a system, program, user, etc. fails, the results of this failure should not propagate into other areas – or at least cause ‘minimal’ damage to others. As a user, if my process fails due to an attempt, say, to execute privileged instructions or access areas not allowed, the results should be localized to this process and this user – nothing else! At the user level, users are given permission / privileges users need and users are given access to those commands that a user needs. That’s it! Computers, running under the principle of least privilege, may be limited to running only certain devices, being able to access only specific remote services, etc, and may be constrained to these devices or services at othr times.

Principles of Protection - 2 While such a philosophy might appear noble and ‘should work for the benefit of all, at least in principle (no pun intended), this principle is implemented in significantly different ways to vastly different degrees as found in very different operating systems. Let’s now look at the Domain of Protection.

Domain of Protection In order to attempt to implement a protection scheme, let’s first look at what we are protecting. First of all, we have hardware objects – CPU, memory segments, printers, disks, etc. We have software objects – file, programs, software switches, … Some measures that may be implemented on some of these objects clearly may not be implementable on others. Some of these devices may only be read. Now, an adjunct to the principle of least privilege is the need to know principle. Does a process need to have access to everything it needs during its entire execution? Perhaps only part of the time?? Again, we are attempting to minimize the risk of security violations.

Domain Structure Fact: Processes need to run within some kind of ‘protection domain.’ The domain indicates what processes can and do not have access to within that domain. The domain is typically accompanied with a set of operations that can be executed on a set of objects (access rights)) We define access rights as: Access-right = <object-name, rights-set> where rights-set is a subset of all valid operations that can be performed on the object. So we have an object names and a set of operations that can be performed on each object within this domain within which ‘the’ process belongs (at this time). All these need not be disjoint. Let’s look more closely at domain structure…

Domain Structure – generic sample Sample: Domain = set of access-rights A domain defines a set of objects and the types of operations that may be performed on these objects. e.g. – a domain containing the access rights: < file F, {readwrite} > that has a program running in it, indicates that this program can execute reads and writes on that file – nothing else on this file, F. The figure also indicates that domains can share access rights. So programs running in both D2 and D3 can both print as it pertains to Object 4

Static and Dynamic Associations Static associations between a process and a domain: – last throughout execution. Dynamic associations between a process and a domain: – can change and is a good bit more complicated. If we have static associations, all permissions would be available throughout execution and this is a problem This is problematic, because as a process executes – in order to support the need-to-know principle, we would need to be able to modify the contents of the domain in response to changing needs. If we do not modify the domain, we are violating the need to know principle. Yet, static association says that all permissions persist throughout the process’ execution.

Static and Dynamic Associations Static associations – between a process and a domain that lasts throughout execution. Dynamic associations – can change and is more complicated. If we have Dynamic Associations: we need to enable the process to switch across domains, and/or we need to be able to modify the content of a domain. If we cannot modify domain contents or switch across domains, then we need to be able to create a new domain with the specific contents we ‘need’ Then we need to be able to switch to this new domain during process execution. We will discuss domain switching ahead… So, what are domains?

Domains A user may be a domain – the set of objects depends upon who the user actually is. New user? New domain. A process may be a domain – set of objects depends exactly on the process undergoing execution. We experience domain switching when one process sends a message to another process and waits for a response. A procedure may be a domain. This is clear: the set of objects that each procedure needs defines that specific domain. Domain switching occurs when control is transferred to a different procedure.

Comment Perhaps as an application programmer, we often don’t see an implementation of some of this. But as an assembler language programmer or a system programmer one sees this all the time. In user mode, (even if writing in assembler) we can execute only non-privileged instructions from the instruction set. This means that there are several assembler language instructions in the overall instruction set that a user cannot execute. A system programmer writing in assembler or in C or in …. has a specific number of additional instructions that one in non-privileged mode doesn‘t have. Instructions that control devices, that poll devices, that set system mask bits, that test semaphores, test and set specific busy bits, etc. and a host of other low level operations – are available to one who is executing in privileged mode. These processes absolutely need to be able to execute these instructions (but no one else!) to accommodate its / their intended functions. Let’s look at how Unix approaches all this.

Domain Implementation (UNIX) In Unix, we have user-domain pairs. If we need to switch the domain, we switch the user id bit for this domain – at least for a while. To clarify: We have an owner-identification bit and a domain bit. In fact, each file has an owner identification and a domain bit (called the setuid bit) associated with it. If the domain bit (setuid) is on: and a user executes that file, the user-id is set to the owner of the file. If the domain bit (setuid) is off: and a user executes that file, the user-id does not change. If userA executes file1 (owned by userB) and setuid is ON, the userid is set to the owner of the file. At the end of the execution, the user-id is reset. If userA executes file1 (owned by userB) and setuid is OFF, the userid of the process is set to A. More closely – next slide.

Domain Implementation (UNIX) Good example from book: We had: If userA executes file1 (owned by userB) and setuid is ON, the userid is set to the owner of the file. At the conclusion of execution, the user-id is reset. If userA executes file1 (owned by userB) and setuid is OFF, the userid of the process is set to A. If we are in an operating environment where user-IDs are used for domain definition, this mechanism will work. We know that in Unix, we can change domains associated with a user. We may need to do this when certain privileged operations might need to be made available to a specific user. Here, for example, we might need to allow users to access a network or database without actually letting them write their own processes to do this. So, in Unix, we can set the domain-bit (setuid) which would cause the user-id to be changed to the owner (a user with network or database privileges) and the user would then gain access to this otherwise privileged process / database – at least temporarily. A downside of this is that when a user is executing a privileged facility, they have infinitely more power than they normally have!!

Access Matrix Consider the following conventions: We can view protection as a matrix (access matrix) Rows represent domains Columns represent objects Access(i, j) is the set of operations that a process executing in Domaini can invoke on Objectj

Access Matrix Here we can see that it is easy to address specific permissions. Above, we have four domains and four objects. We can readily specify permissions that one domain has with respect to file(s) in that particular domain. Note that if executing in Domain 4, a process may have both read and write access to F1 and F3 – in contrast to another process executing in Domain 1.

Implementation of Access Matrix Each Column = Access-control list for one object, say F3. Access Matrix defines who can perform what operation. Domain 1 = Read Domain 3 = Execute Domain 4 = Read, Write  Each Row = Capability List (like a key) say D3 For each domain, what operations allowed on what objects. Object 2 – Read and Write Object 3 – Execute

Access Matrix We can see that such a matrix may be used to specify access The matrix specifies specific access policies. This Access Matrix may also be used as a mechanism to implement access.

Use of Access Matrix (Cont.) Access matrix design separates mechanism from policy. Mechanism Operating system provides access-matrix and rules. It ensures that the matrix is only manipulated by authorized agents and that rules are strictly enforced. Policy User dictates policy, and users normally decide on the contents of the access –matrix entries. When a new object is created, a column is added to the access matrix along with some rights that the creator of the object wishes to enter. These can specify who can access what object and in what mode.

Access Matrix With Domains as Objects In practice, processes need to be able to switch from one domain to another. The property that is implemented is shown below and subscribes to the rule: can change from one domain to another as long as right switch ε access (i,j) This policy (decided by users) and its implementation (controlled by the operating system clearly shows that a process in Domain 2 may switch to Domains 3 or 4.

Use of Access Matrix This Access Control matrix and its implementation may be expanded to dynamic protection. We need specific operations to add, delete access rights. Special desirable access rights: owner of Oi copy op from Oi to Oj control – Di can modify Dj access rights transfer – switch from domain Di to Dj

Access Matrix with Copy Rights We need to be able to copy specific access rights from one domain to another The ability to do so is indicated by an appended asterisk (*) associated with a specific Access (i,j) right. The policy is simple. In (a) we have permissions to copy the read permissions for F2 to any other domain for that object.. Two major points: 1. We can transfer a right by copying a(i,j) to a(k,j) followed by a deletion of this access right from a(i,j). If we elect to copy an access right from one domain to another, this right to ‘copy’ does not extend to the ‘copied to’ domain. Note: there is no asterisk in (b) (D3, F2) .

Access Matrix With Owner Rights Along these same lines, and extending the utility of the matrix to support implementation, it is instructive to note that we can specify a number of ‘other’ access rights including a limited copy as well as a removal of some rights. Observing the access matrices on the right, it is easy to see that if an access right contains the access owner, then the owner can control any access rights for a specific column (object). Here, domain D1 is the owner of F1. So this owner can add or delete any access rights for F1. Further, We see that D2 owns F2 and F3. So, see D2 has added write access to F2 for a process operating in D2. More: the owner of D2, with his ownership of F3, has added a write access right for D3.

Domain Changes The copy and owner rights are sufficient for column access rights. But we need a mechanism to change access entries in a row as well. If a access (i,j) includes the control right, then a process executing in domain Di can remove any access right from row Dj Compare the next two figures and you will observe the modification.

Former Version:

Modified version: Note changes in D2 and D4. The control right is specified in Access (2,4) and is reflected in access changes in D4. control right “Reads” in F1 and F3 are deleted.

End of Chapter 14.1