Protection and Security - PowerPoint PPT Presentation

1 / 62
About This Presentation
Title:

Protection and Security

Description:

on the same system sharing a lot of resources. ... A security policy is a set of acceptable behaviors ... for achieving the intended 'security' for the example: ... – PowerPoint PPT presentation

Number of Views:59
Avg rating:3.0/5.0
Slides: 63
Provided by: liefl
Category:

less

Transcript and Presenter's Notes

Title: Protection and Security


1
Protection and Security
Protection
See lecture slides of Cornell university
http//www.cs.cornell.edu/html/cs513-sp99/
and 2 additional slide sets of Silbershatz
on our course page
2
Protection Security
Motivation Low level Protection High Level
Concepts Access Control List Capability

3
Protection Security
Why do we need Protection?
Since the introduction of open shop and
multiprogramming systems, several users
respectively several applications may run
simultaneously on the same system sharing a lot
of resources. ? We have to control that they do
not interfere on private data, thats why we have
introduced address spaces, i.e. we have to
protect them against each other. However, thats
not sufficient in some cases. Its wise to
protect the system itself against each
application.
4
Protection Security
Functional levels of Information Protection
Unprotected systems (e.g. IBMs DOS and TOPS for
/360 Systems) All or nothing systems (e.g. IBMs
VM/370) - Complete Isolation - Share All
Controlled sharing (TENEX) User-programmed
sharing Putting strings on information
5
Protection Security
No Protection
Sensitive procedures are run at separate times
6
Protection Security
Isolation
  • Each task operates separately from all other
    tasks,
  • with no sharing or communication, i.e. each task
    has its own
  • address space
  • files
  • and other resources
  • Effectively each program runs in an
  • own compartment of the system.

7
Protection Security
Share All
  • The owner of an object (e.g. a file) declares it
    to be
  • public
  • each user can access
  • private
  • only the owner can access

8
Protection Security
Controlled Sharing
The system provides each object (e.g. a file)
with a list of authorized users, - Operating
system checks the permissibility of each
access by a specific user to a specific object -
Operating system acts as the guard
9
Protection Security
User-programmed Sharing (MULTICS, UNIX ...)
An owner of a file may wish to restrict access to
a file In a way not provided by the standard
facilities for controlling sharinng, e.g. -
restrict to certain time periods (weekdays
between 900 am and 400 pm) - restrict read
access to an average value but not to any
individual record - restrcit updates on a file
only if at least 2 users agree ? to protected
subsystems
10
Protection Security
Putting Strings on Information (ADEPT)
Additionally maintain some control over a user
of the information even after it has been
released. Such control is needed - releasing
income information for a tax advisor (he
should not be able to pass this information
to a firm which prepares mailing list etc.) -
printed labels on classified military
information declaring a document to be high
confidential
11
Protection Security
Design Principles for Protection
  • 1. Economy of Mechanism keep design as simple as
    possible
  • 2. Fail-Safe Defaults base access decisions on
    permission
  • rather than on exclusion
  • 3. Complete Mediation every access to every
    object must
  • be checked for authority
  • 4. Open Design the quality of the protection
    schema
  • should not rely on the fact
  • that it is secret.

12
Protection Security
Design Principles for Protection (2)
5. Separation of Privilege where feasible, a
protection mechanism that requires
2 keys to unlock is more robust and
flexible 6. Least Privilege every subject
should operate using the least set of
privileges necessary to complete its
job 7. Least Common Principle minimize the
amount of mechanism common to more than 1
subject (sharing includes always a
danger) 8. Psychological Acceptability human
interface easy to be used, subjects
automatically and routinely apply the
protection mechanism correctly
13
Protection Security
Protection of Memory
  • Single programming system (without virtual
    memory)
  • protect OS against the application

Effect References in user-mode below the value
of the separation-register will raise an
exception (address violation).
Remark You can extend the above idea to more
than one application using 2 limit registers
per application.
14
Protection Security
Protection of Memory
  • Multiprogramming system (with a segmented virtual
    memory)
  • protects OS against applications
  • protects applications against each other

?
physical address within segment
15
Protection Security
Protection of Memory
Segment tables of the tasks are in the address
space of the OS, i.e. each segment table entry
is Completely controlled by the OS. Changes in
these tables can only be made by OS functions.
16
Protection Security
Protection and Sharing of Memory
  • How to avoid that task A
  • overwrites the shared library C?
  • ? Need for further protection bits
  • besides supervisor and user bit

Each segment table entry serves as a
descriptor for Finally accessing the
underlying memory region.
17
Protection Security
Data-Oriented Access Control
  • Associated with each user(subject), there can be
  • a profile specifying permissible operations
    onto objects
  • (user performs a certain job within an
    organization)
  • Associated with each object, you may define
    subjects
  • having access onto that object via certain
    operations
  • An access control matrix may restrict accesses
    onto
  • objects via certain operations by a subset of
    all subjects

18
Protection Security
Access-Control Policies and Mechanisms
Definition A security policy is a set of
acceptable behaviors (e.g. the sequence of
instructions the computer executes or the
sequence of images that appear on the screen).
Policies are defined with respect to abstract
models
Example (from daily life) Only students who
have payed for a course may attend the lectures
of this course
The protection mechanism has to establish a
security policy, e.g. a guard with a list of
students names at the entrance door of
the lecture hall.
19
Protection Security
Access-Control Policies and Mechanisms
Protocol for achieving the intended security
for the example A student walks to the entrance
door of the lecture hall and shows her/his
student ID to the guard. The guard looks up the
students name in his list and if the name is on
the list she/he may enter, otherwise she/he is
rejected.
Is the security policy safe? Is the protection
mechanism safe?
What to do if a student ID is unreadable?
What to do if the student borrows somebody elses
student ID or if she/he enters though the
window instead of the door? What to do if the
lecturer wants to change his security policy,
e.g. he wants to restrict admission to natural
blond female students?
20
Protection Security
Abstract Model of Access-Control
Model (Complete Mediation) Its assumed that
every request by a subject will be checked, and
the decision is based on past actions or other
stored information summarizing those past
actions.
21
Protection Security
Access-Control Matrix
Remark A triple of the form lts,p,ogt with s?S, p
? P and o ? O specifies, that a subject s
may perform an operation p onto an
object o. In practice, an ACM is usually
sparse. Thus we need an appropriate
implementation for all these triples lts, p, ogt.
22
Protection Security
Access-Control Matrix (Silbershatz)
Domain is a widely used notion, e.g. J. Saltzer
uses this notion for all objects that can be
accessed by a principal (subject)
23
Protection Security
Access-Control Matrix (Silbershatz)
  • 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.
  • Operations to add, delete access rights.
  • Special 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

24
Protection Security
Dynamic Access-Control Matrix
  • Systems are not static,
  • i.e. we have to face new subjects and new
    objects,
  • The following operations change the ACM
  • Create_object, i.e. add a new column
  • Create_subject, i.e. add a new row
  • Delete_object, i.e. ...
  • ...
  • grant_operation p to lts,ogt, i.e. add a new right
    to s for o

25
Protection Security
Dynamics with Access Control
Users of a system amy want to play different
roles, each role may demand different p on
the o, e.g. a person being the system
administrator (super user) may not want to
haver super user privileges - when he/she
s just playing a game or - when he/she is
editing mails etc. Even an application task of
the same user does not need to have access to
all objects during ist lifetime, i.e. we want to
be able to adjust the needed access
rights whenever they are needed. We have to
establish small protection domains for
subjects. However, then we have to establish
domain switches.
26
Protection Security
Access-Control Matrix
Discuss why in general the following holds
subjects ? users
Furthermore, sometimes we wish to enable that
subjects are also objects. i.e. S si
? O oj
What does this mean and can you give an
example and how does this affect the concept of
an ACM?
27
Protection Security
Extended Access-Control Matrix (Silbershatzs
notion)
28
Protection Security
Implementation of Access-Control
Why dont we mark all whats forbidden instead of
all whats allowed? 1. Effectiveness If you
forget to allow something that may be a bit
frustrating, later on you still can enhance your
system incrementally. But if you forget to
forbid something thats dangerous, it may be
too late, your system is already corrupted.
29
Protection Security
Implementation of Access-Control
Why dont we mark all whats forbidden instead of
all whats allowed?
2. Efficiency At least in highly sensitive
systems only very few operations onto objects
are really allowed ? only few triples lts, p, ogt
are really existing, whereas many triples lts,
p, ogt are forbidden.
30
Protection Security
Use of Access-Control Matrix
  • Access matrix design separates mechanism from
    policy.
  • Mechanism
  • Operating system provides access-matrix rules.
  • It ensures that the matrix is only manipulated by
    authorized agents and that rules are strictly
    enforced.
  • Policy
  • User or administrator dictates policy.
  • Who can access what object and in what mode.

31
Protection Security
Implementation of Access-Control
Two widely used ways of implementing access
control using a flat schema Object
oriented Collect all entries of a column of the
access control matrix into one data-structure, ?
acces control list (ACL) Subject (principal)
oriented Collect all entries of a row of the
access control matrix into one data-structure, ?
capability
32
Protection Security
Implementation of Access-Control
  • Each column Access-control list for one object
    defining who can perform what operation on that
    object. Subject 1 Read, Write Subject 2
    Read Subject 3 Read
  • Each Row Capability List (like a ticket or a
    key)indicating for each subject, what operations
    are allowed on what objects.
  • Object 1 Read
  • Object 4 Read, Write, Execute
  • Object 5 Read, Write, Delete, Copy

33
Protection Security
Access Control Lists
Each object contains a list indicating which
subjects may access it and how, sometimes
grouping of individual subjects may be supported,
too.
handle object descriptor
access control list
object
type
s1
r,w,x
s2
r
s3
-
s4
-
s5
x
Remark Any access has to be controlled whether
the subject is authorized or not. Unspecified
subjects may have default rights thus allowing
guests etc.
34
Protection Security
Implementation of Access Control Lists
Hint Discuss the pros and cons of the above
35
Protection Security
Example Unix Access Control Lists
Unix differs domains, i.e. pairs of (subjects and
subject-groups) via UIDs and GIDs. Assume we have
4 users Espen, Jimmy, Jochen, Renate belonging
to the groups staff,
system,staff, student, respectively. Some of
the files may have the following ACLs file_0
(Espen, , RWX) file_1 (Jimmy, system,
RWX) file_2 (Espen, staf, RW-),(Jimmy, ,
R--),(Renate, , R--) file_3 (, student,
R--) file_4 (Jochen, , ---), (, student,
R--) usual meta symbol e.g. file_0 can be
read, written, executed by any process with
uidEspen, and any gid file_4 can not be accessed
by Jochen being in any group, but all students
may read this file.
36
Protection Security
Example Unix Access Control Lists
Instead of explicit ACLs Unix offers the 9 bit
scheme rwx rwx rwx for the owner, its group
and all the others Only the owner of a file in
Unix may alter the access rights in the above
mask, however this may not affect users, who had
opened this file before. gt If you never close
a file you still have its previous access rights,
whatever its owner tries to do reduce your
access rights!!!
37
Protection Security
Capability
  • Decomposition of access control matrix by rows
  • Specifies authorized object and operations for a
    user

Definition In a computer system, an
unforgeable ticket, which -when presented- can
be taken as incontestable proof that the
presenter is authorized to have access to the
object named in this ticket.
38
Protection Security
Simple Implementation of Capability
Hint Discuss the pros and cons of this
implementation
39
Protection Security
How to achieve unforgeable capabilities?
Capabilities
Type object type, e.g. file, device,
etc. Access rights bit-map indicating what
interface-functions of
a specified object type are allowed or
not Handle pointer to an explicit object of a
specific type
Protection Constraint A subject must have the
corresponding capability when accessing a
specific object. Forwarding capabilities to other
subjects requires another specific capability.
40
Protection Security
Effective Range of Capabilities
Do we need capabilities for all kinds of objects
and their related operations? Example int
a,b1,c2 a b c Do we need
capabilities for int-operands and the
add-operation?
We can extend the capability-model also to these
simple hardware-related objects but the tinier
the objects and the more frequent the operations
the more well get in heavy trouble with system
performance
41
Protection Security
Capabilities can be viewed as credit cards of a
human subject because bank accounts are objects
worth to be protected
Effective Range of Capabilities
Subjects in the system may have capabilities only
to objects which are worth to be protected!
Subjects
Capabilities
Questions How to map subjects and capabilities,
how to control this mapping,
where to store capabilities.
42
Protection Security
Mapping of Subjects and their capabilities
Assume a subject is a thread, a thread has a TCB,
gt capabilities of this thread are collected
within a list.
TCB
C-List
43
Protection Security
Example of a Capability List
type
access rights
object-ID or handle to object
0 1 2 3
Note Capability lists are themselves objects,
and may be pointed to by other capabilities,
thus facilitating sharing of subdomains.
44
Protection Security
Generic Access Rights onto Capabilities
Additional to object specific access rights the
following generic rights are often used 1. Copy
capability create a new capability for the same
object 2. Copy object create a duplicate object
with a new capability 3. Remove capability
delete an entry from a capability list
object remains
unaffected 4. Destroy object permanently remove
an object and a capability

45
Protection Security
Requirements for Capabilities
Integrity of capabilities?
How can we preserve their integrity? We need
tickets that cannot be forged (compare
unforgeable identity card) 1. Only a authorized
control task of the system may produce,
delete, modify or even transmit a capability to
another subject. 2. Capabilities need additional
protection means.
46
Protection Security
Implementation of Unforgeable Capabilities
  • Three major implementations of unforgeable
    capabilities
  • Isolation
  • Sparsity
  • Encryption

47
Protection Security
Implementation of Isolated Capabilities
  • Tagged memory
  • Special containers
  • Splitted segments

48
Protection Security
Tagged Memory
Pro Normal accesses onto a capability lead to
an exception capability violation Con Very
high cost (gt not available in commercial systems)
49
Protection Security
Special Memory
Pro Comparable fast access to a capability if
you use a TLB for capabilities Con There are
many non segmented systems
50
Protection Security
Splitted Segments
segment B
capabilities
normal data
51
Protection Security
Sparsity Capabilities
Objects-IDs must be space and time unique!
1. Its obvious why we need space unique
object-IDs 2. After deleting an object its
object-ID is free again and might be reused.
However, there might be still some old
capabilities to that object (dangling
reference problem) to be used to access the new
object.
Remark If you use 64 bits for an object-ID, for
585 years you can produce every ns an new
object
52
Protection Security
Encrypted Capabilities
server
object
rights
F(object, rights, check)
check
53
Protection Security
Additional Version Numbers
Each object contains an specific long random
number, the same random number is kept in each
capability for that object.
Note Accesses via non fitting version numbers
are rejected.
54
Protection Security
Implementing Capabilities
Instead of one centralized controlling unit most
capability systems are organized as a collection
of type manager modules. A separate type
manager for each controlled type of object,
i.e. requests to perform file operations are
controlled within the file manager, requests to
perform messages are controlled within the
mailbox server, etc..
55
Protection Security
Revocation Problem
Suppose you want to revoke dynamically in all or
at least some of those capabilities, pointing to
that object. These capabilities are spread all
over the disk
56
Protection Security
Revocation Problem
Suppose you want to revoke dynamically in all or
at least some of those capabilities, pointing to
that object. These capabilities are spread all
over the disk
Why is a pointer back to each capability not a
very good idea?
57
Protection Security
Indirect Capability Handles
Instead of a direct handle to the object, the
handle in the capability points to an object
descriptor finally pointing to the object.
t1
p1, p2
object
object descriptor
t1
p2
t1
p1, p2, p3
58
Protection Security
Indirect Capability Handles
To delete this object , set the object-pointer
to NIL, thats it!
t1
p1, p2
object
object descriptor
t1
p2
Any further reference via one of the
capabilities finds the NIL-pointer in the object
descriptor.
t1
p1, p2, p3
59
Protection Security
Machs Capabilities
Example Mach offers IPC via ports supporting
inter-process communication.
process A
process B
thread 1
Capability with receive right
port x
kernel
1 2 3 4
1 2 3 4
Capability with send right
port y
60
Protection Security
Machs Capabilities (see Tanenbaum, p. 663 ..)
If a thread (in a process) creates a port the
Mach kernel returns a capability for the whole
process, all threads of this process share this
capabilty.
Possible -capability protected- operations on a
Mach port are
  • receive (only one process is allowed to receive
    from a port, however,
  • this port holder may transfer this
    right to another process.
  • Doing so causes it to be removed from
    the senders capability list.)
  • send (more than one process may send to that
    port)
  • send once (allows some-one to send one and only
    one message
  • after doing so the
    kernel destroys this capability.
  • This mechanism is used for request-reply
    protocols, i.e.
  • a client creates a port for the reply message
    from the server.
  • The client send his message
    (all together with a send-once capability)
  • to the server.)

Remark A reference count per capability contains
the involved number of threads per task.
61
Protection Security
Comparing Capabilities and Access Control Lists
  • Capabilities are quite flexible, they are
    protected, permanent handles
  • hard to control propagation of capabilities
  • hard to revoke propagated rights from other
    subjects
  • ACLs allow revoking of rights

62
Protection Security
Subject Type Implementation (Unix)
  • System consists of 2 subject types
  • User
  • Supervisor
  • UNIX
  • subject user-id
  • Subject type switch accomplished via file system.
  • Each file has associated with it a subject type
    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.
Write a Comment
User Comments (0)
About PowerShow.com