CSCI283 Fall 2003 Lecture 8

1
Trusted Operating Systems contd.

• CSCI283 Fall 2003 Lecture 8
• GWU
• Draws extensively from Memons notes, Brooklyn
  Poly
• And text, Chapter 5
• YOU ARE EXPECTED TO READ CHAPTER 5 FROM THE TEXT
  IN ADDITION TO THIS

2
Announcements

• http//www.cacr.math.uwaterloo.ca/hac/
• Handbook of Applied Crypto free online book
  really great reference on all crypto algorithms
• Graduate Events (undergrads very welcome too)
  http//www.cs.gwu.edu/studentcorner/graduateEvent
  s/
• Fri., 7th Nov., 2-330, Graduate Seminar
• Exam 630-830, Wed., 17th Dec., this classroom

3
Announcements Regional ACM Programming Contest

• Contest info   http//www.acm.seas.gwu.edu/icpc/
• 1230pm - 530pm, Saturday, Nov. 8. Marvin Center
  307
• Spectators welcome/solicited
• 4 Web Cameras with live feeds Camera URL
  http//www.acm.seas.gwu.edu/icpc/cameras/
• 15 teams competing at GW, another 142 other teams
  at other sites Competing simultaneously.

4
Clark-Wilson Integrity Model

• In commercial environment we worry about the
  integrity of the data in the system and the
  actions performed upon that data.
• The data is said to be in a consistent state (or
  consistent) if it satisfies given properties.
• For example, let D be the amount of money
  deposited so far today, W the amount of money
  withdrawn so far today, YB be the amount of money
  in all accounts at the end of yesterday, and TB
  be the amount of money in all accounts so far
  today. Then the consistency property is
• D YB W TB

5
CW Model

• A well-formed transaction is a series of
  operations that leave the data in a consistent
  state if the data is in a consistent state when
  the transaction begins.
• The principle of separation of duty requires the
  certifier and the implementers be different
  people.
• In order for the transaction to corrupt the data
  (either by illicitly changing data or by leaving
  the data in an inconsistent state), either two
  different people must make similar mistakes or
  collude to certify the well-formed transaction as
  correct.

6
CW Model

• The Clark-Wilson Model defines data subject to
  its integrity controls as constrained data items
  or CDIs.
• Data not subject to the integrity controls are
  called uncon-strained data items, or UDIs.
• Integrity verification procedures, or IVPs, test
  that the CDIs conform to the integrity
  constraints at the time the IVPs are run. In this
  case, the system is said to be in a valid state.
• Transformation procedures, or TPs, change the
  state of the data in the system from one valid
  state to another TPs implement well-formed
  transactions.

7
CW Model

• Certification Rule 1 (CR1) When any IVP is run,
  it must ensure that all CDIs are in a valid
  state.
• Certification Rule 2 (CR2) For some associated
  set of CDIs, a TP must transform those CDIs in a
  valid state into a (possibly different) valid
  state.
• CR2 defines a certified relation C that
  associates a set of CDIs with a particular TP
• Enforcement Rule 1 (ER1) The system must
  maintain the certified relations, and must ensure
  that only TPs certified to run on a CDI
  manipulate that CDI.

8
CW Model

• Enforcement Rule 2 (ER2) The system must
  associate a user with each TP and set of CDIs.
  The TP may access those CDIs on behalf of the
  associated user. If the user is not associated
  with a particular TP and CDI, then the TP cannot
  access that CDI on behalf of that user.
• This defines a set of triple (user, TP, CDI set
  ) to capture the association of users, TPs, and
  CDIs. Call this relation allowed A. Of course,
  these relations must be certified

9
CW Model

• Enforcement Rule 3 (ER3) The system must
  authenticate each user attempting to execute a
  TP.
• Enforcement Rule 4 (ER4) Only the certifier of a
  TP may change the list of entities associated
  with that TP. No certifier of a TP, or of an
  entity associated with that TP, may ever have
  execute permission with respect to that entity.

10
Examples

• Using the following partial orders, define
  lattices
• Subset of ? ?
• Divisor of ?
• Less than equal to ? ? lower bound?

11
Lattice - Example
G
What can I remove so this is not a lattice?
E
F
D
A
B
C
H
J
12
BLP Simple Version

• The secure flow of information is characterized
  by
• Simple Security Property A subject s may have
  read access to an object o if and only if o ? s o
  ? s
• -Property A subject s who has read access to an
  object o may have write access to an object p
  only if o ? p
• (Contents of a sensitive object can only be
  written to objects at least as high. That is,
  prevent write-down).

13
Biba Integrity Model

• The properties of the Biba Integrity Model are
• Simple Integrity Property Subject s can modify
  (have write access to) object o if and only if
  I(s) gt I(o).
• Integrity -property If subject S has read
  access to object o with integrity level I(o), S
  can have write access to p if and only if I(o) gt
  I(p).

14
Exercise

• Write a set of rules combining the secrecy
  controls of BLP with the integrity controls of
  Biba

15
Dennings requirements

• Information should be able to flow freely among
  members of a single class reflexivity.
• Information flow should be transitive.
• BLP exhibits both characteristics.
• However, information flow policies are more
  general and need not be transitive and even if
  they are may not be modeled by a lattice.
• These are rules, need them to be consistent. Show
  that BLP exhibits both characteristics

16
Confinement Flow Models

• Each entity, a, is assigned a confinement pair
  confine(a) (aL aU) where aL is the lowest
  classification of information allowed to flow out
  of a and aU is the highest classification of
  information allowed to flow into a.
• Example Confine(x) Confidential,
  Confidential
• Confine(y)
  Secret, Secret
• Confine(z) Confidential,
  Topsecret
• Possible flows? Secure or allowed flows?
  Transitive?
• Graph

17
Compiler-Based Mechanisms

• Need some language construct to relate variables
  to security classes.
• Example x integer class A B may mean
  that security classes A and B may flow into x.
• Assignment statements
• x y z
• for this to be a secure flow luby, z lt x.
• Draw representative graph

18
Compiler-Based Mechanisms

• Conditional Statements
• if x y lt z then
• a b
• else
• d b c x
• Requirement for secure flow is
• 1. b lt a
• 2. lub b, c, x lt d
• 3. lub x, y, z lt gub a, d
• Draw graph

19
Execution Based Mechanisms

• Consider
• if x 1 then y a else y b
• Information flows from x and a or x and b to
  y. But if a lt y only if some other variable z
  is 1 then compiler has no way of checking this.
  Need run time mechanisms.

20
You need to know

• How to tell if X can access Y from a graph
• How to tell if something dominates something
  else, in integrity or confidentiality
• How to tell if a graph is a lattice
• How to construct a lattice given an example
• How to determine secure flows from a piece of
  pseudo-code or a graph.
• How to tell if a graph is consistent with a given
  model/pseudo-code

21
Need

• Policy description of requirements
• Model policy representation check if policy can
  be enforced
• Design implementation of policy
• Trust based on features and assurance

22
Harrison-Ruzzo-Ullman (HRU) Model

• Can be used to answer questions like
• Can user X ever have access to object Y?
• Commands that consist of conditions and primitive
  operations

23
HRU - command

• command name(o1, o2, o3, on)
• if r1 in As1,o1 and
• r2 in As2,o2 and
• rm in Asm,om
• then
• op1
• op2
• opk
• end

24
HRU - Primitive operations, op

• create subject s
• create object o
• destroy subject s
• destroy object o
• enter right r into As, o
• delete right r from As, o
• Operations are enough to model, for example, the
  Unix protection mechanism

25
Can show that

• In the HRU modelled system,
• If commands are restricted to one operation each,
  it is possible to decide whether a given subject
  can ever obtain a particular right to an object
• If commands are not restricted to one operation
  each, it is not always decidable whether a given
  protection system can confer a given right

26
Take-Grant system

• Primitive operations create, revoke, take, grant
• Can we decide if a given object can share an
  object with another subject? Yes.
• Can we decide if a given subject can steal access
  to an object from another subject? Yes.
• Proofs use representation of properties as graphs

27
Operations represented as graphs
r
O
S
S
Create Object
q ? r
q
Revoke Right
S
O
O
S
28
More operations as graphs
r
r
Grant
r
Grant
P
S
O
P
S
O
r
r
Take
Take
P
S
O
P
S
O
29
Need

• Policy description of requirements
• Model policy representation check if policy can
  be enforced
• Design implementation of policy
• Trust based on features and assurance

30
Design Principles for Secure Systems

• Two basic themes
• Simplicity KISS
• Makes design and interactions easy
• Easy to prove its safety
• Restriction
• Minimize the power of entities
• Compartmentalization
• Common Sense!

31
Principles of design

1. Principle of least privilege
2. Principle of fail-safe defaults
3. Principle of economy of mechanism
4. Principle of complete mediation
5. Principle of open design
6. Principle of separation of privilege
7. Principle of least common mechanism
8. Principle of psychological acceptability

32
Principle of least privilege

• Entity should be given only those privilege
  needed to finish a task
• Function/role should control the rights
• Temporary elevation of privilege should be
  relinquished immediately
• Granularity of privileges

33
Principle of fail-safe defaults

• Unless a subject is given explicit access to an
  object, it should be denied access to the object.
• Default access to an object is none
• If subject is unable to complete its task before
  it terminates it should undo changes made to the
  state of the system.
• Restricting privileges at the time of creation

34
Principle of economy of mechanism

• Security mechanism should be as simple as
  possible.
• Fewer errors
• Testing and verification is easy
• Assumptions are less

35
Principle of complete mediation

• All accesses to objects should be checked to
  ensure they are allowed. Illegitimate access
  attempts should be expected and protected against
  
• Security vs. performance issues

36
Principle of open design

• Security of a mechanism should not depend upon
  secrecy of its design or implementation
• Secrecy ! security
• Complexity ! security
• Security through obscurity
• Cryptography and openness
• AES

37
Principle of separation of privilege

• System should not grant permission based on
  single condition
• Company checks over 75,000 to be signed by two
  officers.

38
Principle of least common mechanism

• Mechanisms used to access resources should not be
  shared
• Why?

39
Principle of psychological acceptability

• Security mechanism should not make the resource
  difficult to access
• Recognizes the most important element in computer
  security?

Human
40
Design Principles for Privacy

• Fair information practices - US Privacy Act of
  1974.
• Openness and transparency No secret record
  keeping. This includes both the publication of
  existence, as well as contents.
• Individual participation The subject of a record
  should be able to see and correct the record.
• Collection limitation Data collection should be
  proportional to the purpose of the collection.

41
Design Principles for Privacy -2

• Data quality Data should be relevant to the
  purposes for which they are collected and should
  be kept up to date.
• Use limitation Data should only be used for
  their specific purpose by authorized personnel.
• Reasonable security Adequate security safeguards
  should be put in place, according to the
  sensitivity of the data collected.
• Accountability Record keepers must be
  accountable for compliance with the other
  principles.

42
Need

• Policy description of requirements
• Model policy representation check if policy can
  be enforced
• Design implementation of policy
• Trust based on features and assurance

43
Trusted OS Features

• ID and Authentication
• Mandatory and Discretionary Access Control
• Object Reuse Protection
• Complete Mediation
• Trusted Path (makes Trojan Horse intercepting
  data/man in the middle more difficult)
• Accountability and Audit Log
• Audit Log Reduction issues too much, too
  little, how to make sense?
• Intrusion Detection statistical analysis of logs

44
Security Kernel

• Enforces security mechanisms of entire OS
  provides security interfaces among h/w, OS, other
  parts
• Covers all object access
• Can isolate security mechanisms
• Compactness sometimes
• Modularity change, test etc. Can be verified,
  analyzed through forma methods, etc.

45
Parts of the security kernel

• Reference Monitor controls access. Needs to be
  small and tamperproof. Part of TCB.
• Trusted Computing Base (TCB) everything
  necessary to enforce security policy.
• TCB constituted of
• h/w
• processes and interprocess communication
• primitive files
• protected memory

46
Parts of TCB

• TCB constituted of
• h/w
• processes and interprocess communication
• primitive files
• protected memory
• Not in TCB user apps, user environment,
  directories, procedures, memory management

47
TCB function

• Process Activation
• Requires complete change of registers, file
  access lists, process status info.
• Execution domain switch when processes in one
  domain invoke processes in other domains
• Memory Protection
• I/O

48
HW

• Read up on Microsofts Trusted Windows plan, once
  known as Palladium.
• Critique it. Find Bill Arbaughs comments on
  TCPA.
• Do not turn in, I will ask questions in class.