Chapter 14: Protection

1
Chapter 14 Protection
2
Chapter 14 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
• Capability-Based Systems
• Language-Based Protection

3
Objectives

• Discuss the goals and principles of protection in
  a modern computer system
• Explain how protection domains combined with an
  access matrix are used to specify the resources a
  process may access
• Examine language-based protection systems

4
Background

• Protection and Security are related yet very
  different topics.
• We will devote a chapter to each.
• Protection requires two things
• A Policy what it is we want, and
• Implementation mechanisms how we are going to
  do it.
• Protection is a measure of confidence that the
  integrity of a system and its data will be
  preserved.
• Security assurance is a much broader topic and we
  will cover it next chapter.
• One may view Protection as some kind of mechanism
  for controlling access of programs, processes, or
  users to resources defined by a computer system
  perhaps system resources perhaps user
  resources.
• The mechanism for implementing these controls
  must be specified.
• And there must also be a means of enforcement and
  not simply policy.

5
Goals of Protection

• We know that operating systems consist of large
  collections of objects, hardware and software
• All users of such a computer system share these
  same resources.
• Clearly, we need to protect these shared
  resources from intentional or accidental
  activities which may prove to be disastrous.
• Since all these resources are shared, we
  definitely need policies to govern and control
  appropriate access.
• Specifically, policies need to define authorized
  and unauthorized access.

6
Policy and Implementation - 1

• Policies may be fixed in the design of the
  computing system
• Other policies may be developed by management of
  the computing system.
• Still other policies may be implemented by users
  themselves to protect their own files and
  programs.
• Thus a protection system must include the ability
  to enforce a number of different policies.
• Operating system designers can implement
  protection mechanisms as integral parts of the OS
  (a protection kernel perhaps).
• Application develops may also develop protection
  mechanism and in some cases these desires are
  supported by their choice of programming
  language.
• While these will clearly differ in scope and
  extent, both are needed.
• We now define an object as a unique name that can
  be accessed through a well-defined set of
  operations.
• So, the protection problem is to ensure that each
  object is accessed correctly and only by those
  processes allowed to do so.

7
Policy and Implementation - 2

• In this chapter, we will emphasize what an
  operating system can/should provide.
• Using these facilities, an application developer
  may then select some of his/her own protection
  approaches, as mentioned.
• Note that having mechanisms how something
  will be done, differs markedly from policies,
  which address what will be done.
• Policies can change from time to time.
  Conceivably, policy changes may result in changes
  to underlying mechanisms.
• This is always the way things are done
• The what followed by the how.
• Clearly related, but vastly different!

8
Principles of Protection

• The criterion that is used to guide design and
  implementation issues for protection is the
  principle of least privilege.
• Basically, this principle says that one should
  have enough privileges to do what one needs to do
  but nothing more!
• One of the advantages of this approach is that if
  a system, program, user, etc. fails, the results
  of this failure should not propagate into other
  areas or at least cause minimal damage to
  others.
• As a user, if my process fails due to an attempt,
  say, to execute privileged instructions or access
  areas not allowed, the results should be
  localized to this process and this user nothing
  else!
• At the user level, users are given permission /
  privileges users need and users are given access
  to those commands that a user needs. Thats it!
• Computers, running under the principle of least
  privilege, may be limited to running only certain
  devices, being able to access only specific
  remote services, etc, and may be constrained to
  these devices or services at othr times.

9
Principles of Protection - 2

• While such a philosophy might appear noble and
  should work for the benefit of all, at least in
  principle (no pun intended), this principle is
  implemented
• in significantly different ways
• to vastly different degrees as found
• in very different operating systems.
• Lets now look at the Domain of Protection.

10
Domain of Protection

• In order to attempt to implement a protection
  scheme, lets first look at what we are
  protecting.
• First of all,
• we have hardware objects CPU, memory segments,
  printers, disks, etc.
• We have software objects file, programs,
  software switches,
• Some measures that may be implemented on some of
  these objects clearly may not be implementable on
  others.
• Some of these devices may only be read.
• Now, an adjunct to the principle of least
  privilege is the need to know principle.
• Does a process need to have access to everything
  it needs during its entire execution? Perhaps
  only part of the time??
• Again, we are attempting to minimize the risk of
  security violations.

11
Domain Structure

• Fact Processes need to run within some kind of
  protection domain.
• The domain indicates what processes can and do
  not have access to within that domain.
• The domain is typically accompanied with a set of
  operations that can be executed on a set of
  objects (access rights))
• We define access rights as Access-right
  ltobject-name, rights-setgtwhere rights-set is a
  subset of all valid operations that can be
  performed on the object.
• So we have an object names and a set of
  operations that can be performed on each object
  within this domain within which the process
  belongs (at this time).
• All these need not be disjoint.
• Lets look more closely at domain structure

12
Domain Structure generic sample

• Sample Domain set of access-rights
• A domain defines a set of objects and the types
  of operations that may be performed on these
  objects.
• e.g. a domain containing the access rights lt
  file F, readwrite gt that has a program running
  in it, indicates that this program can execute
  reads and writes on that file nothing else on
  this file, F.
• The figure also indicates that domains can share
  access rights. So programs running in both D2
  and D3 can both print as it pertains to Object 4

13
Static and Dynamic Associations

• Static associations between a process and a
  domain
• last throughout execution.
• Dynamic associations between a process and a
  domain
• can change and is a good bit more complicated.
• If we have static associations, all permissions
  would be available throughout execution and this
  is a problem
• This is problematic, because as a process
  executes in order to support the need-to-know
  principle, we would need to be able to modify the
  contents of the domain in response to changing
  needs.
• If we do not modify the domain, we are violating
  the need to know principle.
• Yet, static association says that all permissions
  persist throughout the process execution.

14
Static and Dynamic Associations

• Static associations
• between a process and a domain that lasts
  throughout execution.
• Dynamic associations
• can change and is more complicated.
• If we have Dynamic Associations
• we need to enable the process to switch across
  domains, and/or
• we need to be able to modify the content of a
  domain.
• If we cannot modify domain contents or switch
  across domains, then we need to be able to create
  a new domain with the specific contents we need
  
• Then we need to be able to switch to this new
  domain during process execution.
• We will discuss domain switching ahead
• So, what are domains?

15
Domains

• A user may be a domain the set of objects
  depends upon who the user actually is.
• New user? New domain.
• A process may be a domain set of objects
  depends exactly on the process undergoing
  execution.
• We experience domain switching when one process
  sends a message to another process and waits for
  a response.
• A procedure may be a domain.
• This is clear the set of objects that each
  procedure needs defines that specific domain.
• Domain switching occurs when control is
  transferred to a different procedure.

16
Comment

• Perhaps as an application programmer, we often
  dont see an implementation of some of this. But
  as an assembler language programmer or a system
  programmer one sees this all the time.
• In user mode, (even if writing in assembler) we
  can execute only non-privileged
  instructions from the instruction set.
• This means that there are several assembler
  language instructions in the overall instruction
  set that a user cannot execute.
• A system programmer writing in assembler or in C
  or in . has a specific number of additional
  instructions that one in non-privileged mode
  doesnt have.
• Instructions that control devices, that poll
  devices, that set system mask bits, that test
  semaphores, test and set specific busy bits, etc.
  and a host of other low level operations are
  available to one who is executing in privileged
  mode.
• These processes absolutely need to be able to
  execute these instructions (but no one else!) to
  accommodate its / their intended functions.
• Lets look at how Unix approaches all this.

17
Domain Implementation (UNIX)

• UNIX
• In Unix, we have user-domain pairs.
• If we need to switch the domain, we switch the
  user id bit for this domain at least for a
  while.
• To clarify
• We have an owner-identification bit and a domain
  bit.
• In fact, each file has an owner identification
  and a domain bit (called the setuid bit)
  associated with it.
• If the domain bit (setuid) is on
• and a user executes that file, the user-id is set
  to the owner of the file.
• If the domain bit (setuid) is off
• and a user executes that file, the user-id does
  not change.
• If userA executes file1 (owned by userB) and
  setuid is ON, the userid is set to the owner of
  the file.
• At the end of the execution, the user-id is
  reset.
• If userA executes file1 (owned by userB) and
  setuid is OFF, the userid of the process is set
  to A.
• More closely next slide.

18
Domain Implementation (UNIX)

• Good example from book
• We had
• If userA executes file1 (owned by userB) and
  setuid is ON, the userid is set to the owner of
  the file.
• At the conclusion of execution, the user-id is
  reset.
• If userA executes file1 (owned by userB) and
  setuid is OFF, the userid of the process is set
  to A.
• If we are in an operating environment where
  user-IDs are used for domain definition, this
  mechanism will work.
• We know that in Unix, we can change domains
  associated with a user.
• We may need to do this when certain privileged
  operations might need to be made available to a
  specific user.
• Here, for example, we might need to allow users
  to access a network or database without actually
  letting them write their own processes to do
  this.
• So, in Unix, we can set the domain-bit (setuid)
  which would cause the user-id to be changed to
  the owner (a user with network or database
  privileges) and the user would then gain access
  to this otherwise privileged process / database
  at least temporarily.
• A downside of this is that when a user is
  executing a privileged facility, they have
  infinitely more power than they normally have!!

19
Access Matrix

• Consider the following conventions
• We can 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

20
Access Matrix
Here we can see that it is easy to address
specific permissions. Above, we have four domains
and four objects. We can readily specify
permissions that one domain has with respect to
file(s) in that particular domain. Note that
if executing in Domain 4, a process may have both
read and write access to F1 and F3 in
contrast to another process executing in Domain 1.
21
Implementation of Access Matrix

• Each Column Access-control list for one object,
  say F3. Access Matrix defines who can perform
  what operation. Domain 1 Read Domain 3
  Execute Domain 4 Read, Write ?
• Each Row Capability List (like a key) say
  D3For each domain, what operations allowed on
  what objects.
• Object 2 Read and Write
• Object 3 Execute

22
Access Matrix
We can see that such a matrix may be used to
specify access The matrix specifies specific
access policies. This Access Matrix may also be
used as a mechanism to implement access.
23
Use of Access Matrix (Cont.)

• Access matrix design separates mechanism from
  policy.
• Mechanism
• Operating system provides access-matrix and
  rules.
• It ensures that the matrix is only manipulated by
  authorized agents and that rules are strictly
  enforced.
• Policy
• User dictates policy, and users normally decide
  on the contents of the access matrix entries.
• When a new object is created, a column is added
  to the access matrix along with some rights that
  the creator of the object wishes to enter.
• These can specify who can access what object and
  in what mode.

24
Access Matrix With Domains as Objects
In practice, processes need to be able to switch
from one domain to another. The property that is
implemented is shown below and subscribes to the
rule can change from one domain to another
as long as right switch e access (i,j) This
policy (decided by users) and its implementation
(controlled by the operating system clearly
shows that a process in Domain 2 may switch to
Domains 3 or 4.
25
Use of Access Matrix

• This Access Control matrix and its implementation
  may be expanded to dynamic protection.
• We need specific operations to add, delete access
  rights.
• Special desirable 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

26
Access Matrix with Copy Rights

• We need to be able to copy specific
• access rights from one domain to another
• The ability to do so is indicated by an
• appended asterisk () associated with
• a specific Access (i,j) right.
• The policy is simple.
• In (a) we have permissions to copy the
• read permissions for F2 to any other domain for
• that object..
• Two major points
• 1. We can transfer a right by copying a(i,j) to
• a(k,j) followed by a deletion of this access
  right
• from a(i,j).
• If we elect to copy an access right from one
• domain to another, this right to copy does not

27
Access Matrix With Owner Rights
Along these same lines, and extending the
utility of the matrix to support implementation,
it is instructive to note that we can specify
a number of other access rights including a
limited copy as well as a removal of some
rights. Observing the access matrices on the
right, it is easy to see that if an access right
contains the access owner, then the owner can
control any access rights for a specific column
(object). Here, domain D1 is the owner of F1.
So this owner can add or delete any access
rights for F1. Further, We see that D2 owns F2
and F3. So, see D2 has added write access to F2
for a process operating in D2. More the owner
of D2, with his ownership of F3, has added a
write access right for D3.
28
Domain Changes

• The copy and owner rights are sufficient for
  column access rights.
• But we need a mechanism to change access entries
  in a row as well.
• If a access (i,j) includes the control right,
  then a process executing in domain Di can remove
  any access right from row Dj
• Compare the next two figures and you will observe
  the modification.

29
Former Version
30
Modified version Note changes in D2 and D4. The
control right is specified in Access (2,4) and is
reflected in access changes in D4.
control right
Reads in F1 and F3 are deleted.
31
End of Chapter 14.1