1. Chapter 14-2 Protection

2. 14.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 14-2: 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 Language-Based Protection

3. 14.3 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Objectives Discuss the Implementation of Access Matrix approach Discuss Revocation of Access Rights Consider Language-based protection Compiler-based, and Protection in Java

4. 14.4 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Implementation of Access Matrix

5. 14.5 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Implementation of Access Matrix So, we know about these access matrices, but how can we actually use them to implement and enforce protection? We will consider four approaches: A Global Table Access Lists for Objects Capability Lists for Domains, and Locks and Key Mechanisms

6. 14.6 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Global Table Simplest approach, but not in widespread use due to some inherent limitations. Idea is to have sets of ordered triples. When some Operation M is executed on an Object O with Domain D, the global table is searched for this triple such that M ε R, where R is the ‘rights-set’. If found, the operation may continue If not found, an exception is raised. There is a real downslides to this simplicity. Size of Global Table. Specifically, as one can imagine, the Global Table can be very large Consequently, it usually cannot be kept in primary memory If we have processes with many input/output operations, for example, we will have seriously degraded overall system performance. There are other issues here too, but this is the primary one.

7. 14.7 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Access Lists for Objects This approach is often used as a component of a solution. Here we have a list of ordered pairs that is associated with each object. For each object, we have a pair:. This list for each object cites domains and their appropriate rights-set (of course, the rights-set set may vary from domain to domain). Importantly, if we use this approach, the list of ordered pairs is accompanied by a default set of access-rights. As it turns out, it is the default set that is usually checked first. If some process, M, is found in the default set, access is allowed. If not, then the larger, more involved access list consisting of sets of ordered pairs is searched.

8. 14.8 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Capability Lists for Domains A capability list for a specific domain is simply a list of objects coupled with the operations allowed on those objects. A capability itself simply refers to some kind of object. This object (capability) is represented by a physical name or an address. The notion of a capability is used a lot in protection schemes. So, operationally, when we have some kind of operation, M, that needs to take place on some object. Access to Capability List. It is important to note here that the capability list for a domain is never accessed nor is it permitted to be accessed by the process executing in this domain. Thus the capability list for a domain is a protected object and it is maintained by the OS. The capability list is accessed only indirectly by the user. So a user may never have direct access to a capability list and thus has no opportunity to modify the capability list. Also, please note that capabilities are special objects and are not to be considered data. Both hardware and/or firmware ensure that these objects are safeguarded from being migrated into an address space of a user process.  Most systems use some kind of combination of access lists and capabilities.

9. 14.9 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Lock and Key Mechanisms Compromise. The Lock and Key Mechanism approach is another approach that finds itself as a compromise between access lists and capability lists. In this scheme, each object is given a unique bit pattern called a lock and each domain has a list of unique bit patterns called keys. So, an executing process in a specific domain may only have access to an object for which its key matches a lock of an object in that domain. Again, most systems use a combination of access lists and capability lists.

10. 14.10 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Revocation of Access Rights

11. 14.11 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Revocation of Access Rights Access Rights can be revoked. Differences in Revocation. There are differences in revoking access rights when comparing implementation using Access Lists and Capability Lists. Access List – Rights can be deleted right from access list. These are pretty simple. Simple Immediate Capability List – Here, there is a scheme required to locate capability in the system before capability can be revoked. This approach is much more involved, and you might consider reading through these issues. I won’t pursue this further.

12. 14.12 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Language-Based Protection

13. 14.13 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Language-Based Protection Protection implementation – given the data structures, ordered-triples, ordered pairs, lists of access rights, etc. – is often accommodated via kernel software. But some languages, such as Java, provide additional (often more flexible levels) of protection. Kernel Protection. If we are considering protection via the kernel, recognize that “… comprehensive access validation is potentially a source of considerable overhead” as one can readily realize. Yes, it will be reliable and comprehensive, but the overhead can be significant! Great care must be exercised in providing this capability so as not to make the protection capability itself (projection kernel) too large and too comprehensive to ensure the level of protection desired. As it turns out, protection mechanisms are no longer only concerned with the identity of the desired resource, but also with the functional nature of that access. This means that there the concern is no longer limited to protection of system-defined functions that we commonly invoked, such as many system calls and other key services associated with accessing ‘sacred’ kernel data structures or files (for example), but this protection now extends to user-defined functions too. While this can be good, it ushers in complexity as well. So nowadays protection not only falls under the purview of the operating system designer, but also the application programmer may deal with protection via extensions to the implementing languages that help the developer protect resources against malicious or unintended access.

14. 14.14 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Langauge-based Protection (more) A few more comments – from book: Specification of protection within some programming languages allows the high-level description of policies directly impacting the allocation and use of resources. Language implementation efforts at protection can further provide software for protection enforcement when automatic hardware-supported checking is unavailable. (more ahead on this)

15. 14.15 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Compiler-Based Enforcement One way using compiler-based support is to use an extension of the typing facility. Protection is indicated along with data typing So, a program designer may declare desired protection along with data typing as long as it is available with the programming language features. This information must be coded into the application for the compiler to enforce / require it. There is also the assumption that compiler-based protection assumes no code generated by the compiler will be modified during process execution. Simple to Use. Using this approach, protection needs should be easily declared in the language and can be independent of any of (and supplemental to) protections supplied by the operating system. Given this approach, then, once established, enforcement does not have to be accommodated by the designer of the resource for which protection is desired.

16. 14.16 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Compiler-based Enforcement - 2 However done, there is the assumption/perception that support is provided by the operating system kernel. Further, it is important to note that any security provided by programming language declarations will typically not be as robust as those implemented in kernel modules (although it will be much more flexible). Dependency on OS. Protection, as found in programming language declarations, does depend upon what’s going on in the system itself, which, of course, the OS monitors and controls. So what we are saying is that any compiler-based enforcement receives some oversight by the OS and the environment it controls. But, in using compiler-generated facilities via a language does allow us to distinguish between references that have violations and those that do not – and these can treated differently than those that might be treated exclusively by the operating system.

17. 14.17 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Enforcement only by a Protection Kernel Greater security.(from the text) Using kernel protection, there is no dependency on  Security that might be generated by a translator,  Some underlying mechanism of storage management that protects the segments from which compiled code is executed, – Many examples here…and more. The kernel has a much more secure set of parameters in this regard. Restrictions on where the protection kernel it is located (typically in fixed storage segments) and other constraints virtually eliminate some concerns that might be found in using compiler-enforced protection.. Flexibility. Programming Language Support.  Here, protection using a programming language only needs to be declared for a specific implementation and hence can be very specific.  Here too, the level of protection maybe extended as needed. Kernel Support.  Kernel support is designed to support its own policies and consequently may be very limited in implementing the user policy.  Extensions of the level of kernel support would be much more significant and impact overall protection.

18. 14.18 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Efficiency Greatest efficiency occurs (no surprise) when enforcement of protection is provided by hardware (or microcode). Language Support. Language support is good because static access enforcement can be handled off-line at compile time, but this is not the case when only the protection kernel is used. Kernel Support vs. Language Support. Further, the enforcement mechanism can be tailored to specific needs in the language support, whereas there is a lot of overhead with kernel calls for sure.

19. 14.19 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Summary When we use programming language specifications for protection, we can implement a high-level description of policies for the allocation and use of resources. A real plus is that language implementation can provide software for protection enforcement when automatic hardware-supported checking is unavailable. Moreso, language-based protection can interpret protection specifications to generate calls on whatever protection system is provided by the language and the operating system.

20. 14.20 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Protection in Java Specification of protection in Java or some other programming languages allows the high- level description of policies for the allocation and use of resources. Consider: Note that Java was designed for the development of applications running in a distributed environment and because of this, the Java Virtual Machine (JVM) has a lot of built-in protection mechanisms. Protection in Java is accommodated by the JVM. Recall:  We know Java has classes and objects consisting of attributes (properties) and methods (functions).  We know that objects are instances of classes and provide for encapsulation, information hiding, abstraction, and modularity. So, we know Java can dynamically load untrusted (and trusted) classes over a network. Similarly, Java can execute distrusting classes within the same JVM too. Because of the why the JVM operates, Java really has got to provide for and enforce protection, because the operating system is ‘underneath’ the JVM. When requests are issued, honoring them depends upon which class has requested the open.  Again, protection in Java is handled by the JVM.

21. 14.21 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Protection in Java - more When JVM loads a class, it is assigned to a protection domain that gives the permissions of that class. The protection domain to which a class is assigned depends on the URL from which the class was loaded and any digital signatures on the class. (see ahead) The protection domain indicates what operations the class can (and cannot) perform. Configuration Policy File. Much control in Java is sometimes implemented by a configuration policy file This file determines the permissions granted to the domain and its classes. Example. Classes downloaded from a trusted server, for example, might be given wider access than those downloaded from an untrusted server. Library class. In Java we have a library class specifically used to permit access to, say, a network connection to load a requested URL. The requesting message must explicitly assert the privilege to access the resource. Thus, it is the method that takes on the responsibility for the request.  Recall in Java, objects present services available to clients and thus have responsibilities. Hopefully, the method will also undertake other checks to ensure the safety of the request. “Of course, not every method is allowed to assert a privilege; a method can assert a privilege only if its class is in a protection domain that is itself allowed to exercise the privilege.”

22. 14.22 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts A Definition - JVM A Java Virtual Machine (JVM) is a set of computer software programs and data structures which use a virtual machine model for the execution of other computer programs and scripts. The model used by a JVM accepts a form of computer intermediate language commonly referred to as Java byte-code.

23. 14.23 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts A Definition - Digital Signature A digital signature or digital signature scheme is a type of asymmetric cryptography. For messages sent through an insecure channel, a properly implemented digital signature gives the receiver reason to believe the message was sent by the claimed sender. Digital signatures are equivalent to traditional handwritten signatures in many respects; properly implemented digital signatures are more difficult to forge than the handwritten type. Digital signature schemes are cryptographically based, and must be implemented properly to be effective. Digital signatures can also provide non-repudiation, meaning that the signer cannot successfully claim they did not sign a message, while also claiming their private key remains secret; further, some non- repudiation schemes offer a time stamp for the digital signature, so that even if the private key is exposed, the signature is valid nonetheless.

24. End of Chapter 14.2