CMSC 414 Computer (and Network) Security Lecture 12

1
CMSC 414Computer (and Network) SecurityLecture
12

• Jonathan Katz

2
Midterm?

• Will be held Oct 21, in class
• Will cover everything up to and including the
  preceding lecture (Oct 16)
• Includes all reading posted on the class syllabus!

3
Homework review?

• Questions on HWs 1 or 2??

4
Integrity policies (Chapter 6)
5
Some requirements/assumptions

• Users will not write their own programs
• Will use existing programs and databases
• Programs will be written/tested on a
  nonproduction system
• Special process must be followed to install new
  program on production system

6
Requirements, continued

• The special installation process is controlled
  and audited
• Auditors must have access to both system state
  and system logs

7
Some corollaries

• Separation of duty
• Basically, have multiple people check any
  critical functions (e.g., software installation)
• Separation of function
• Develop new programs on a separate system
• Auditing
• Recovery/accountability

8
Biba integrity model

• Ordered integrity levels
• The higher the level, the more confidence
• More confidence that a program will act correctly
• More confidence that a subject will act
  appropriately
• More confidence that data is trustworthy
• Note that integrity levels may be independent of
  security labels
• Confidentiality vs. trustworthiness
• Information flow vs. information modification

9
Information transfer

• An information transfer path is a sequence of
  objects o1, , on and subjects s1, , sn-1, such
  that, for all i, si can read oi and write to oi1
• Information can be transferred from o1 to on via
  a sequence of read-write operations

10
Low-water-mark policy

• s can write to o if and only if the integrity
  level of s is higher than that of o
• The information obtained from a subject cannot be
  more trustworthy than the subject itself
• If s reads o, then the integrity level of s is
  changed to min(i(o), i(s))
• The subject may be relying on data less
  trustworthy than itself

11
Continued

• s1 can execute s2 iff the integrity level of s1
  is higher than the integrity level of s2
• Note that, e.g., s1 provides inputs to s2 so s2
  cannot be more trustworthy than s1

12
Security theorem

• If there is an information transfer path from o1
  to on, then i(on) ? i(o1)
• Informally information transfer does not
  increase the trustworthiness of the data

13
Drawbacks of this approach

• The integrity level of a subject is
  non-increasing
• A subject will soon be unable to access objects
  at high integrity levels
• Does not help if integrity levels of objects are
  lowered instead
• Downgrades the integrity level of trustworthy
  information

14
Ring policy

• Only deals with direct modification
• Any subject may read any object
• s can write to o iff i(o) ? i(s)
• s1 can execute s2 iff i(s2) ? i(s1)
• The difference is that integrity levels of
  subjects do not change
• Security theorem holds here as well

15
Strict integrity policy

• Bibas model
• s can read o iff i(s) ? i(o)
• s can write o iff i(o) ? i(s)
• s1 can execute s2 iff i(s2) ? i(s1)
• Note that read/write are both allowed only if
  i(s) i(o)
• Security theorem holds here as well

16
Lipners basic model

• Based loosely on Bell-LaPadula
• Two security levels
• Audit manager (AM)
• System low (SL)
• Five categories
• Development (D) - production programs under
  development
• Production code (PC) - processes/programs
• Production data (PD)
• System development (SD) - system programs under
  development
• Software tools (T) - programs unrelated to
  protected data

17
Lipners model, continued

• Assign users to levels/categories e.g.
• Regular users (SL, PC, PD)
• Developers (SL, D, T)
• System auditors (AM, D, PC, PD, SD, T)
• Etc.

18
Lipners model, continued

• Objects assigned levels/categories based on who
  should access them e.g.
• Ordinary users should be able to read production
  code, so this is labeled (SL, PC)
• Ordinary users should be able to write production
  data, so this is labeled (SL, PC, PD)
• Follows Bell-LaPadula methodology

19
Properties

• This satisfies the initial requirements
• Users cannot execute category T, so they cannot
  write their own programs
• Developers do not have read/write access to PD,
  so cannot access production data
• If they need production data, the data must first
  be downgraded to D (this requires sys admins)
• Etc.

20
Lipners full model

• Augment security classifications with integrity
  classifications
• Now, a subjects access rights to an object
  depend on both its security classification and
  its integrity classification
• E.g., subject can read an object only if
  subjects security class is higher and subjects
  integrity class is lower

21
Clark-Wilson model (highlights)

• Transactions are the basic operation
• Not subjects/objects
• The system should always remain in a consistent
  state
• A well-formed transaction leaves the system in a
  consistent state
• Must also verify the integrity of the
  transactions themselves

22
Access control mechanisms (Chapter 15)
23
The problem

• Drawbacks of access control matrices
• In practice, number of subjects/objects is large
• Most entries blank/default
• Matrix is modified every time subjects/objects
  are created/deleted

24
Access control lists (ACLs)

• Instead of storing central matrix, store each
  column with the object it represents
• Stored as pairs (s, r)
• Subjects not in list have no rights
• Can use wildcards to give default rights

25
Example Unix

• Unix divides users into three classes
• Owner of the file
• Group owner of the file
• All other users
• Note that this leaves little flexibility
• Some systems have been extended to allow for more
  flexibility
• Abbrev. ACLs overridden by explicit ACLs

26
Modifying ACLs

• Only processes which own the object can modify
  the ACL of the object
• Sometimes, there is a special grant right
  (possibly per right)

27
Privileged user?

• How do ACLs apply to privileged user?
• E.g., in Solaris both abbreviations of ACLs and
  full ACLs are used
• Abbreviated ACLs ignored for root, but full ACLs
  apply even to root

28
Groups/wildcards?

• Groups and wildcards reduce the size and
  complexity of ACLs
• E.g., user group r
• group r
• user r