Lecture 34

Questions?
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
1
Outline

Protection vs. security

Protection domains

Access matrix

Implementations


Access lists, capability lists

Unix
Language-based protection
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
2
Protection vs. Security

The last topics for this class. Definition of each
is somewhat arbitrary:


Protection (Chapter 14): making sure that
accesses by users, program, and subsystems are
authorized, and do not cause inconsistencies. I.e.,
make a reliable system. This is an internal OS
issue.
Security (Chapter 15): dealing with the external
environment. Making sure that only authorized
users gain access; prevent malicious destruction or
alteration of data; prevent denial of service.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
3
Protection

There are two parts to protection schemes



Policy: the rules that govern how resources are to
be used
Mechanism: OS support for enforcing the policy
We will focus on mechanism. Looking for
general mechanisms that can be used to
enforce any policy. Want it to be efficient in
space and time.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
4
Protection Domains


Consider computer system as a collection of
processes and objects (both hardware and
software). Each object has a name and
operations that may be performed on it.
Processes should be allowed to access only
those objects and operations for which it is
authorized, and that is needed to complete the
current task.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
5
Protection Domains

Each process is given a protection domain
(PD). A PD is a set of access rights (written
<obj, {ops}>) that specify what objects may be
accessed and the operations that may be
invoked by processes with that PD.
D1
D2
D3
< O3, {read, write} > < O2, {write} >
< O1, {execute} >
< O1, {read, write} > < O4, {print} >
< O3, {read} >
< O2, {execute} >
< O4, {print} >
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
6
Protection Domains


PDs may be disjoint (e.g., D1) or may have
shared access rights (e.g., D2 and D3 share
<O4, {print}>)
Association of process to PD can be static or
dynamic. If static, the domain will need to be
alterable to enforce any need-to-know policy.
E.g., read-only phase followed by a write-only
phase. Usually, association is dynamic and a
process can switch between domains.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
7
Protection Domains

PDs can be defined in different ways



Based on user identity. E.g. Unix. Switch PDs by
logging in as a different user.
Based on process identity. E.g. TOPS-20. Switch
PDs by asking another process to do task.
Simple example: a single-tasking OS has 2
modes - kernel and user - that also are the
PDs. OS in kernel domain; user in user
domain. Some operations can be done only in
kernel mode, so ask OS to do them.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
8
Access Matrix

Most general model of PDs is as an access
matrix.
object
dom
F1
D1
read
F2
F3
read
D2
read
read,
write
Wednesday, April 4
D2
D3
D4
switch
print
D3
D4
Printer D1
switch switch
exec
switch
CS 470 Operating Systems - Lecture 34
9
Access Matrix



Define access(i,j) to be the set of operations
on Oj that a process in PD Di can invoke.
Policy decides what entries are put into the
matrix. Users usually set entries for their own
objects.
Also used in domain switching. If "switch" is a
member of access(i,j), the process in PD D i can
switch to PD Dj.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
10
Access Matrix

The access matrix is an object itself. Need to
control changes to the contents. Added rights:



copy: allows process in Di to copy the right to any
other entry in the same column. This can be a full
copy, a transfer, or a limited copy (cannot copy the
copy right).
owner: allow a process in Di to add to and remove
objects from Dj
control: allow changes to entries in a domain (i.e.,
row). Allows process in Di to change entries in Dj.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
11
Implementing PDs



Implementing PDs has many issues. The
access matrix is sparse, but standard
techniques do not work well.
Could have a global table of <domain, object,
rights set> entries. When operation M is
executed on object Oj in PD Di, look for entry
<Di,Oj,Rk> where M  Rk.
Generally too large for main memory and
cannot do groupings. E.g., everyone has read
right means an entry in every PD.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
12
Access Lists


A common implementation is an access list.
There is one list per object of <domain,
rights set> entries.
Extend idea with default set of rights. When M
is executed is executed on object O j in PD Di,
search Oj's access list for <Di, Rk> and M  Rk.
If not found, look in default list (or vice versa).
Basically, each list is a column in the matrix.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
13
Capability Lists


Can also implement PDs by making each row
of the access matrix into a list of capabilities of
the form <object, {operations}>.
Often can use a capability as a kind of secure
pointer. Possession of the capability
immediately implies the right to perform the
listed operations. No need to check. Of
course, this makes capability manipulation a
kernel mode operation that can only be done by
the OS.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
14
Unix Protection


Unfortunately, capability-based systems, and
even access-list systems, are too slow. Most
OS's use something similar to the Unix
protection scheme.
In Unix, a PD is defined on the file system only,
and is based on user identity. There are 3 PDs:
owner, group, world. There are 3 operations:
"read", "write", "execute". The rights to perform
these operations is a bit vector represented as
the familiar: rwxrwxrwx
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
15
Unix Protection


Usually, a process runs in the PD of the
invoking user. But there are a few limited ways
to switch PDs while a process is running.
If a program file has its setuid bit set
(represented with an 's' in the owner execute bit
position), then the program runs in the PD of
the owner of the file. It is said to be running
with an effective UID of the file owner. PD
switches back to the original PD when program
completes.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
16
Unix Protection



E.g., passwd program is owned by root and
has setuid bit set so that it can change the
various password files that are owned by root.
Main problem with this scheme is that it may be
possible for a user to run such a program in a
way that executes some other code while the
process is effectively running as root.
This is the basis for the buffer overrun exploits.
Want to be careful with setuid. Unix also has
setgid for group rights, which is a little safer.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
17
Other Schemes

Alternately, can disallow switching PDs entirely.
Then must provide a special process (called a
daemon) to accept requests and perform the
service. E.g. Kerberos login authentication
system.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
18
Language-Based Protection

Efforts to gain more control over protection
issues has led to integrating statements about
resources into programming languages. This
has several advantages:




protection needs are declared rather than
programmed as calls to the OS
protection is described independently of the
facilities provided by the OS
enforcement is automatic and does not require a
separate subsystem to be designed
privileges are closely related to concept of type
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
19
Language-Based Protection


Of course, would want to map compiler-based
protection checking onto provided OS facilities
where possible for efficiency, but can always
generate software checks.
Java 2 is an example. As a language it has


strong type-checking; in particular cannot convert
an int into a pointer
private class data cannot be accessed directly
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
20
Language-Based Protection


The JVM allows dynamic loading of classes in
response to requests to create instances.
Since these classes can come from different
sources (including over the network), some are
more trusted than others.
Process-based protection is not enough, since
the OS would need to know what class is being
requested, too. So PDs are associated with
each class and depend on the class' URL and
digital signature. The JVM handles checking.
Wednesday, April 4
CS 470 Operating Systems - Lecture 34
21