Silberschatz, Galvin and Gagne 2002 18.1 Operating System Concepts Chapter 18: Protection Goals of...

Silberschatz, Galvin and Gagne 200218.1Operating System Concepts

Chapter 18: Protection

Goals of Protection Objects and Domains Access Matrix Implementation of Access Matrix Revocation of Access Rights Capability-Based Systems Language-Based Protection


Protection

Operating system consists of a collection of objects, hardware or software: buffers, registers, memory regions, PCB’s, files, directories, etc.

Each object has a unique name and can be accessed through a well-defined set of operations. For files those operations are: read, write, execute.

Protection problem - ensure that each object is accessed correctly and only by those processes that are allowed to do so.


Domain Structure

Domains are entities that might want to access the objects: processes, programs, users, roles.

Domain granularity There may be just 2 domains in the system: users and the

superuser There may be a domain for each user There may be several domains per user: user surfing web,

user compiling programs, user changing his password, etc.


Access Matrix

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

Figure A


Use of Access Matrix

If a process in Domain Di tries to do “op” on object Oj, then “op” must be in the access matrix.

Can be expanded to dynamic protection. Domains are objects, also the access matrix itself. Operations to add, delete access rights. Special access rights:

owner of Oi

copy op on Oi to another domain

control – Di can modify Dj access rights

transfer – switch from domain Di to Dj


Use of Access Matrix (Cont.)

Access matrix design separates mechanism from policy. Mechanism

Operating system provides access-matrix + rules. If ensures that the matrix is only manipulated by

authorized agents and that rules are strictly enforced. Policy

User dictates policy. Who can access what object and in what mode.


Implementation of Access Matrix

Sparse matrix (list of access right/domain pairs) or Access control lists or Capability lists

Each column = Access-control list for one object Defines who can perform what operation.

Domain 1 = Read, WriteDomain 2 = ReadDomain 3 = Read

Each Row = Capability List (like a key)For each domain, what operations allowed on what objects.

Object 1 – ReadObject 4 – Read, Write, ExecuteObject 5 – Read, Write, Delete, Copy


Access Matrix of Figure A With Domains as Objects

Fig B: A process executing in D1 can switch to D2


Access Matrix with Copy Rights

A process in D2 can copy the read op on F2

to another domain


Access Matrix With Owner Rights

D1 owns F1 and controls access rights of other

domains on F1


Modified Access Matrix of Figure B

A process in D2 can modify the rights of D4


Access Control or Capability Lists?

Theoretically these implementations are the same: any protection state that can be represented in one can be represented in the other. In practice, some actions are just impractical in one implementation or the other.

Removing a user (because he left the company) is more efficient in capability lists.

Changing a file to read-only for everyone (“february-sales” is made read-only when February is over) is easier in ACLs.


Implementation Considerations

In a given implementation, new lists can be created or changed easily, whereas the items in the lists must be well-defined and unchanging.

Creating a new domain or splitting a current one is easy in capability lists. “domainB as manager” and “domainB as payroll person”.

The result is that capability list systems create fine-grained domains. This makes it easy to enforce the principle of least privilege – a fundamental principle in computer security.


ACL Systems

In ACL systems, the password program and many system utilities, like compilers, run as “root” since the available domains are limited.

Suppose you discover that the password file is kept in /x/y/z (or the IDS logs showing that you tried to break into the system). You invoke the compiler and specify that it should write the output to /x/y/z !!!

This (and many other problems) can be patched in ACL systems, but it never exists as a problem in capability list systems.


Capability-Based Systems

Capability lists Password-program: /x/y/z, read, write Compiler: /usr/bin/prog, read Jholliday: /usrs/faculty/jholliday, read, write, owner

A new domain is created: Compiler-jholliday: /user/bin/prog, read;

/usrs/faculty/jholliday, write Note: this domain does not have the capability to write

to /x/y/z UNIX, an ACL system, handles this type of problem with

the setuid bit but this has lead to many security problems. Each file has associated with it a domain bit (setuid bit). When file is executed and setuid = on, then user-id is set to

owner of the file being executed. When execution completes user-id is reset.


Language-Based Protection

Specification of protection in a programming language allows the high-level description of policies for the allocation and use of resources.

Language implementation can provide software for protection enforcement when automatic hardware-supported checking is unavailable.

Interpret protection specifications to generate calls on whatever protection system is provided by the hardware and the operating system.


Protection in Java 2

Protection is handled by the Java Virtual Machine (JVM)

A class is assigned a protection domain when it is loaded by the JVM.

The protection domain indicates what operations the class can (and cannot) perform.

If a library method is invoked that performs a privileged operation, the stack is inspected to ensure the operation can be performed by the library.

Silberschatz, Galvin and Gagne 2002 18.1 Operating System Concepts Chapter 18: Protection Goals of...

Documents

Transcript of Silberschatz, Galvin and Gagne 2002 18.1 Operating System Concepts Chapter 18: Protection Goals of...