Chapter 14-2 Protection. 14.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts...

Chapter 14-2 ProtectionChapter 14-2 Protection

14.2 Silberschatz, Galvin and Gagne ©2005Operating System Concepts

Chapter 14-2: ProtectionChapter 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


ObjectivesObjectives

Discuss the Implementation of Access Matrix approach

Discuss Revocation of Access Rights

Consider Language-based protection

Compiler-based, and

Protection in Java



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


Global Table

Simplest approach, but not in widespread use due to some inherent limitations.

Idea is to have sets of ordered triples <domain, object, rights-set>. 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.


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: <domain, rights-set>.

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.


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.


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.


Revocation of Access RightsRevocation of Access Rights


Revocation of Access RightsRevocation 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.


Language-Based Protection


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.


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)


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.


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.


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.


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.


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.


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.


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.”


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.


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.

End of Chapter 14.2End of Chapter 14.2

Chapter 14-2 Protection. 14.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts...

Documents

Transcript of Chapter 14-2 Protection. 14.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts...